Sono sconcertato e spero che qualcun altro riconoscerà i sintomi di questo problema.
Hardware: nuovo Dell T110 II, Pentium G850 dual-core da 2,9 GHz, controller SATA integrato, un nuovo disco rigido cablato da 500 GB 7200 RPM all'interno della scatola, altre unità all'interno ma non ancora montate. Nessun RAID. Software: nuova macchina virtuale CentOS 6.5 con VMware ESXi 5.5.0 (build 1746018) + client vSphere. 2,5 GB di RAM allocati. Il disco è il modo in cui CentOS si è offerto di configurarlo, vale a dire come volume all'interno di un gruppo di volumi LVM, tranne per il fatto che ho saltato avendo un / home separato e semplicemente ho / e / boot. CentOS viene aggiornato, ESXi corretto, gli ultimi strumenti VMware installati nella VM. Nessun utente sul sistema, nessun servizio in esecuzione, nessun file sul disco ma l'installazione del sistema operativo. Sto interagendo con la VM tramite la console virtuale della VM in vSphere Client.
Prima di andare oltre, volevo verificare di aver configurato le cose più o meno ragionevolmente. Ho eseguito il seguente comando come root in una shell sulla VM:
for i in 1 2 3 4 5 6 7 8 9 10; do
dd if=/dev/zero of=/test.img bs=8k count=256k conv=fdatasync
done
Vale a dire, basta ripetere il comando dd 10 volte, il che si traduce in una stampa della velocità di trasferimento ogni volta. I risultati sono inquietanti. Si inizia bene:
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.451 s, 105 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 20.4202 s, 105 MB/s
...
ma dopo 7-8 di questi, poi stampa
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GG) copied, 82.9779 s, 25.9 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 84.0396 s, 25.6 MB/s
262144+0 records in
262144+0 records out
2147483648 bytes (2.1 GB) copied, 103.42 s, 20.8 MB/s
Se aspetto un periodo di tempo significativo, ad esempio 30-45 minuti, e lo eseguo di nuovo, torna di nuovo a 105 MB / s, e dopo diversi round (a volte alcuni, a volte 10+), scende a ~ 20- 25 MB / s di nuovo.
In base alla ricerca preliminare di possibili cause, in particolare VMware KB 2011861 , ho modificato lo scheduler di I / O Linux in " noop" anziché in quello predefinito. cat /sys/block/sda/queue/schedulermostra che è in vigore. Tuttavia, non riesco a vedere che ha fatto alcuna differenza in questo comportamento.
Tracciando la latenza del disco nell'interfaccia di vSphere, mostra i periodi di latenza del disco elevata che raggiungono 1,2-1,5 secondi durante i periodi in cui viene ddriportato il throughput basso. (E sì, le cose non rispondono mentre succede.)
Che cosa potrebbe causare questo?
Sono a mio agio che non è dovuto al guasto del disco, perché avevo anche configurato altri due dischi come volume aggiuntivo nello stesso sistema. All'inizio ho pensato di aver fatto qualcosa di sbagliato in quel volume, ma dopo aver commentato il volume da / etc / fstab e aver riavviato, e aver provato i test su / come mostrato sopra, è diventato chiaro che il problema è altrove. Probabilmente è un problema di configurazione ESXi, ma non ho molta esperienza con ESXi. Probabilmente è qualcosa di stupido, ma dopo aver cercato di capirlo per molte ore per più giorni, non riesco a trovare il problema, quindi spero che qualcuno possa indicarmi la giusta direzione.
(PS: sì, so che questa combinazione hardware non vincerà alcun premio di velocità come server e ho motivi per utilizzare questo hardware di fascia bassa e eseguire una singola macchina virtuale, ma penso che sia oltre il punto per questa domanda [a meno che è in realtà un problema hardware].)
APPENDICE # 1 : Lettura altre risposte come questa mi ha fatto provare ad aggiungere oflag=directa dd. Tuttavia, non fa alcuna differenza nello schema dei risultati: inizialmente i numeri sono più alti per molti round, quindi scendono a 20-25 MB / s. (I numeri assoluti iniziali sono compresi nell'intervallo di 50 MB / s.)
ADDENDUM # 2 : L'aggiunta sync ; echo 3 > /proc/sys/vm/drop_cachesnel loop non fa alcuna differenza.
ADDENDUM # 3 : per eliminare ulteriori variabili, ora corro in modo ddtale che il file che crea sia maggiore della quantità di RAM sul sistema. Il nuovo comando è dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. I numeri di throughput iniziale con questa versione del comando sono ~ 50 MB / s. Scendono a 20-25 MB / s quando le cose vanno a sud.
ADDENDUM # 4 : Ecco l'output di iostat -d -m -x 1esecuzione in un'altra finestra del terminale mentre le prestazioni sono "buone" e poi di nuovo quando sono "cattive". (Mentre sta succedendo, sto correndo dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct.) In primo luogo, quando le cose sono "buone", mostra questo:
Quando le cose vanno "male", iostat -d -m -x 1mostra questo:
ADDENDUM # 5 : su suggerimento di @ewwhite, ho provato a utilizzare tunedprofili diversi e ho anche provato iozone. In questo addendum, riporto i risultati della sperimentazione con il fatto che tunedprofili diversi abbiano influito sul ddcomportamento sopra descritto. Ho provato a cambiare il profilo in virtual-guest, latency-performancee throughput-performance, mantenendo tutto il resto uguale, riavviando dopo ogni modifica e poi ogni volta in esecuzione dd if=/dev/zero of=/test.img bs=16k count=256k conv=fdatasync oflag=direct. Non ha influito sul comportamento: proprio come prima, le cose iniziano bene e molte ripetizioni ripetute ddmostrano le stesse prestazioni, ma poi ad un certo punto dopo 10-40 corse, le prestazioni diminuiscono della metà. Successivamente, ho usato iozone. Questi risultati sono più estesi, quindi li inserisco come appendice n. 6 di seguito.
ADDENDUM # 6 : su suggerimento di @ewwhite, ho installato e utilizzato iozoneper testare le prestazioni. L'ho eseguito con tunedprofili diversi e ho utilizzato un parametro di dimensione file massima (4G) molto grande iozone. (La VM ha 2,5 GB di RAM allocati e l'host ne ha 4 GB in totale.) L'esecuzione di questi test ha richiesto del tempo. FWIW, i file di dati non elaborati sono disponibili ai collegamenti seguenti. In tutti i casi, il comando utilizzato per produrre i file era iozone -g 4G -Rab filename.
- Profilo
latency-performance:- risultati non elaborati : http://cl.ly/0o043W442W2r
- Foglio di calcolo Excel (versione OSX) con grafici: http://cl.ly/2M3r0U2z3b22
- Profilo
enterprise-storage:- risultati non elaborati : http://cl.ly/333U002p2R1n
- Foglio di calcolo Excel (versione OSX) con grafici: http://cl.ly/3j0T2B1l0P46
Quello che segue è il mio sommario.
In alcuni casi ho riavviato dopo una precedente esecuzione, in altri casi non l'ho fatto e ho semplicemente eseguito iozonenuovamente dopo aver modificato il profilo con tuned. Ciò non sembra fare la differenza evidente per i risultati complessivi.
tunedProfili diversi non sembravano (ai miei occhi certamente inesperti) influenzare il comportamento generale riportato da iozone, sebbene i profili influenzassero alcuni dettagli. In primo luogo, non sorprende che alcuni profili abbiano modificato la soglia alla quale le prestazioni sono diminuite per la scrittura di file di grandi dimensioni: tracciando i iozonerisultati, è possibile vedere una scogliera a 0,5 GB per il profilo, latency-performancema questo calo si manifesta a 1 GB sotto il profiloenterprise-storage. In secondo luogo, sebbene tutti i profili mostrino una strana variabilità per combinazioni di file di piccole dimensioni e dimensioni di record ridotte, il modello preciso di variabilità differiva tra i profili. In altre parole, nei grafici mostrati di seguito, il motivo irregolare nella parte sinistra esiste per tutti i profili, ma le posizioni delle fosse e la loro profondità sono diverse nei diversi profili. (Tuttavia, non ho ripetuto esecuzioni degli stessi profili per vedere se il modello di variabilità cambia notevolmente tra esecuzioni dello iozonestesso profilo, quindi è possibile che ciò che assomiglia alle differenze tra i profili sia in realtà solo una variabilità casuale.)
Di seguito sono riportati i grafici di superficie dei diversi iozonetest per il tunedprofilo di latency-performance. Le descrizioni dei test vengono copiate dalla documentazione per iozone.
Leggi test: questo test misura le prestazioni della lettura di un file esistente.
Scrivi test: questo test misura le prestazioni della scrittura di un nuovo file.
Lettura casuale: questo test misura le prestazioni della lettura di un file con l'accesso a posizioni casuali all'interno del file.
Scrittura casuale: questo test misura le prestazioni della scrittura di un file con l'accesso a posizioni casuali all'interno del file.
Fread: questo test misura le prestazioni della lettura di un file usando la funzione di libreria fread (). Questa è una routine di libreria che esegue operazioni di lettura bufferizzate e bloccate. Il buffer si trova nello spazio degli indirizzi dell'utente. Se un'applicazione dovesse leggere trasferimenti di dimensioni molto ridotte, la funzionalità I / O bufferizzata e bloccata di fread () può migliorare le prestazioni dell'applicazione riducendo il numero di chiamate effettive al sistema operativo e aumentando le dimensioni dei trasferimenti durante il sistema operativo le chiamate sono fatte.
Fwrite: questo test misura le prestazioni della scrittura di un file utilizzando la funzione di libreria fwrite (). Questa è una routine di libreria che esegue operazioni di scrittura nel buffer. Il buffer si trova nello spazio degli indirizzi dell'utente. Se un'applicazione dovesse scrivere in trasferimenti di dimensioni molto ridotte, la funzionalità I / O bufferizzata e bloccata di fwrite () può migliorare le prestazioni dell'applicazione riducendo il numero di chiamate effettive al sistema operativo e aumentando le dimensioni dei trasferimenti durante il sistema operativo le chiamate sono fatte. Questo test sta scrivendo un nuovo file, quindi di nuovo l'overhead dei metadati è incluso nella misurazione.
Infine, durante il periodo in cui iozoneho svolto le sue attività, ho anche esaminato i grafici delle prestazioni per la VM nell'interfaccia client di vSphere 5. Sono passato avanti e indietro tra i grafici in tempo reale del disco virtuale e il datastore. I parametri di stampa disponibili per il datastore erano maggiori rispetto al disco virtuale e i grafici delle prestazioni del datastore sembravano rispecchiare ciò che stavano facendo i dischi e i dischi del disco virtuale, quindi qui allego solo un'istantanea del grafico del datastore presa dopo aver iozoneterminato (sotto il tunedprofilo latency-performance). I colori sono un po 'difficili da leggere, ma ciò che forse è più notevole sono i picchi verticali acuti in letturalatenza (ad es. alle 4:25, poi di nuovo leggermente dopo le 4:30 e di nuovo tra le 4: 50-4: 55). Nota: la trama è illeggibile quando è incorporata qui, quindi l'ho anche caricata su http://cl.ly/image/0w2m1z2T1z2b
Devo ammettere che non so cosa fare di tutto questo. In particolare, non capisco gli strani profili di buche nelle aree di record piccoli / file di dimensioni piccole dei iozonegrafici.
iostate ha mostrato un utilizzo del 90% sia prima che dopo. Ma non sono un esperto nel giudicare queste cose - forse la saturazione sta avvenendo da qualche parte. Sto aggiornando la mia domanda per mostrare l' iostatoutput nel caso sia utile.
