Warning: Illegal string offset 'addMap' in /home/mhd-01/www.gabcicala.it/htdocs/wp-content/plugins/mygeopositioncom-geotags-geometatags/mygeopositioncom-geotags-geometatags.php on line 639
Warning: Illegal string offset 'position' in /home/mhd-01/www.gabcicala.it/htdocs/wp-content/plugins/mygeopositioncom-geotags-geometatags/mygeopositioncom-geotags-geometatags.php on line 561
Warning: Illegal string offset 'position' in /home/mhd-01/www.gabcicala.it/htdocs/wp-content/plugins/mygeopositioncom-geotags-geometatags/mygeopositioncom-geotags-geometatags.php on line 603
Una tematica sempre viva nella implementazione di una architettura complessa per la erogazione di un servizio web è su come fare un buon tuning del file system per trovare la giusta combinazione tra velocità e sicurezza del file. Velocità sia nella scrittura che nella lettura del dato e sicurezza che questo non venga perso per eventi accidentali.
A questo link (http://wiki.centos.org/HowTos/Disk_Optimization) ho trovato alcuni buoni consigli per poter fare questo tuning e devo dire che calza abbastanza al caso mio: una macchina DELL R710 con 4 dischi da 1TB in modalità RAID 5; con lo scopo di erogare file via web-services.
Ho fatto delle prove su diversi file system usando i tool di testing quali Bonnie++ e Iozone. Ma prima di cambiare tipo di file system ho voluto provare a fare il tuning di quello che generalmente uso, ovvero il tipo ext3.
Le info necessarie per i settaggi sono state controllate direttamente a livello del controller PERC H700 che attualmente monta una Dell PE R710, come si vede dalla figura inclusa.
Le opzioni di creazione della partizione sono state:
:~# mkfs.ext3 -b 4096 -E stride=16 -E stripe-width=48 -O dir_index /dev/xxxx
E interrogando la partizione in oggetto ottengo le seguenti info:
:~# tune2fs -l /dev/xxxx tune2fs 1.41.6 (30-May-2009) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 4f5416fd-963d-4cbb-baf6-0db9b385ba88 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 183042048 Block count: 732168183 Reserved block count: 36608409 Free blocks: 720628010 Free inodes: 183042037 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 849 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 RAID stripe width: 48 Filesystem created: Fri Dec 17 17:23:34 2010 Last mount time: n/a Last write time: Fri Dec 17 17:32:06 2010 Mount count: 0 Maximum mount count: 36 Last checked: Fri Dec 17 17:23:34 2010 Check interval: 15552000 (6 months) Next check after: Wed Jun 15 18:23:34 2011 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: 0a4ecd73-58f9-4675-9dfe-f90cf0f7f667 Journal backup: inode blocks
Altre opzioni da seguire sono le opzioni di “mounting” e nel mio caso penso che seguirò la “noatime” come consigliato dalla guida sopra citata.
Ad ogni modo vedremo come andrà durante i test successivi che non mancheranno. Ovviamente i consigli sono ben accetti.