È lento IO sul mio server di cloud causando i miei problemi di riavvio del server lento?

Sto eseguendo due server su una nube Rackspace per l'applicazione web e uno per le istanze db e redis. Il server web dispone di 1Gb di ram e di un singolo nucleo. Nginx si siede di fronte a unicorno che gestisce due lavoratori. Ho anche un'istanza sidekiq in esecuzione. Questa configuration funziona in modo ottimale e i server generalmente sbarrano lungo la CPU molto bassa poiché l'applicazione non è ancora stata lanciata.

Tuttavia, quando faccio un riavvio unicorno, per non parlare di un'applicazione completa, tutto l'inferno diventa allentato. Sembra qualcosa di simile: Questo non è un grande grafico

In pratica il mio server viene eliminato per 3 minuti. È talvolta reattivo a volte ma il monitoraggio sta triggersndo avvisi di interruzione in tutto il luogo (questo è solo il riavvio di zero).

Se faccio una distribuzione completa, il grafico si estende per circa 8 minuti anche se sto precompilando le risorse e caricando, quindi non compilazione sul server.

La parte interessante per me è che ho un'impostazione esatta del server duplicato in esecuzione su DigitalOcean. Posso completamente riavviare l'intera shutdown -r server shutdown -r e essere in su e servire le pagine in 50 secondi. Con questo server Rackspace non daren't riavviarlo neanche per testare come mi darebbe molto tempo significativo per un server di produzione.

Io non sono un amministratore del server di Linux, quindi mi chiedo se le persone possono dirmi se questo è il par per il corso con server cloud Rackspace. Ho avuto un'esperienza decennale in esecuzione di alcune scatole dedicate di Windows e non ho mai avuto problemi come questo.

hdparm contro i server.

Rackspace:

 $ sudo hdparm -Tt /dev/xvdc /dev/xvdc: Timing cached reads: 5066 MB in 1.99 seconds = 2541.54 MB/sec Timing buffered disk reads: 238 MB in 3.00 seconds = 79.32 MB/sec 

DigitalOcean

 $ sudo hdparm -Tt /dev/vda /dev/vda: Timing cached reads: 15612 MB in 1.99 seconds = 7828.02 MB/sec Timing buffered disk reads: 1416 MB in 3.00 seconds = 471.89 MB/sec 

Ovviamente il server DO supera il server RS ​​con un margine significativo. Abbastanza interessante, il server DO sta effettivamente in scena due applicazioni, quindi sta facendo più lavoro di quello RS. Entrambe le hdparm funzionano con il carico del server circa lo stesso (cioè molto poco). È questa velocità di disco puramente lenta o se qualcos'altro sta succedendo?

superiore per entrambi i server

Rackspace

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9832 xxxxxxxx 20 0 525m 214m 4372 S 0.0 21.6 1:31.61 ruby 9829 xxxxxxxx 20 0 443m 205m 3312 S 0.0 20.6 1:27.67 ruby 15597 xxxxxxxx 20 0 554m 176m 1268 S 0.0 17.8 4:59.36 ruby 9780 xxxxxxxx 20 0 443m 63m 1088 S 0.0 6.4 0:28.80 ruby 787 root 20 0 193m 17m 2608 S 2.0 1.7 350:43.06 driveclient 1556 xxxxxxxx 20 0 77876 11m 1020 S 0.0 1.1 18:54.78 remote_syslog 17415 root 20 0 73096 3364 2608 S 0.0 0.3 0:00.03 sshd 

Oceano digitale

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 20921 xxxxxxxx 20 0 240m 191m 5328 S 0.0 19.1 0:29.62 ruby 21009 xxxxxxxx 20 0 204m 178m 5356 S 0.0 17.8 0:20.82 ruby 21194 xxxxxxxx 20 0 204m 174m 1724 S 0.0 17.4 0:00.10 ruby 21206 xxxxxxxx 20 0 204m 174m 1656 S 0.0 17.4 0:00.10 ruby 21181 xxxxxxxx 20 0 98.3m 89m 2184 S 0.3 8.9 0:03.04 ruby 1426 xxxxxxxx 20 0 117m 40m 2272 S 0.0 4.1 1:09.02 ruby 1429 xxxxxxxx 20 0 117m 29m 2180 S 0.0 3.0 1:09.64 ruby 1422 xxxxxxxx 20 0 117m 4652 1172 S 0.0 0.5 0:08.08 ruby 22066 xxxxxxxx 20 0 7188 3456 1512 S 0.0 0.3 0:00.09 bash 22008 root 20 0 10008 3320 2664 S 0.0 0.3 0:00.03 sshd 

Dovrei sterminarmi su Rackspace?

Modifica: implementa il grafico (escluso il caricamento e la decompressione di file di elementi precompilati)

Questo non è il grafico di una distribuzione felice

Modifica: vmstat

 $ vmstat -SM 1 10 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- rb swpd free buff cache si so bi bo in cs us sy id wa 1 0 380 67 13 109 4 4 13 10 10 17 1 1 97 0 0 0 380 67 13 109 0 0 0 0 650 1011 0 1 99 0 0 0 380 67 13 109 0 0 0 0 675 1008 0 1 99 0 0 0 380 67 13 109 0 0 0 0 659 1009 0 0 100 0 1 0 380 67 13 109 0 0 0 68 661 1027 0 0 99 1 0 0 380 67 13 109 0 0 0 0 667 1014 0 0 100 0 1 0 380 67 13 109 0 0 0 0 671 1016 1 0 99 0 0 0 380 67 13 109 0 0 0 0 668 1008 0 0 99 0 0 0 380 67 13 109 0 0 0 0 671 1022 0 0 100 0 0 0 380 67 13 109 0 0 0 0 783 1112 9 3 89 0 

3 Solutions collect form web for “È lento IO sul mio server di cloud causando i miei problemi di riavvio del server lento?”

Lavoro a Rackspace e vorremmo aiutarti a risolvere questo problema. Se poteste chiamarci a 1-800-961-4454 possiamo controllare la salute dell'host che il tuo server è acceso e spostarlo in un nuovo se sembra essere un problema rumoroso vicino. Mi piacerebbe anche vedere l'output di 'vmstat -SM 1 10', 'sar -b' (dopo un po 'di tempo passato) e forse' iostat -x / dev / xvdc 2 6 'quando questo problema sta avvenendo.

Grazie!

-Jimmy

Dai dati che hai inviato, questo è sicuramente un bottleneck I / O sul server rackspace. Come dimostra chiaramente il tuo grafico, la maggior parte del tempo della CPU viene spesa con I / O-attesa (cioè la CPU sta aspettando che i processi di I / O finisca).

Ciò è di solito causato dalla velocità del disco lento e, poiché si tratta di un'istanza virtuale, probabilmente altri casi utilizzano gran parte dell'I / O del hostsystem. Non vedo molto che si potrebbe fare a less di trovare un altro hoster (o convincerli a migrare in un altro hostsystem con less carico I / O o get un altro server su un hostsystem diverso e provare se quello è meglio).

Ciò sembra certamente un collo di bottiglia I / O, forse causato da un vicino rumoroso.

Rackspace ti sposta in un altro host inserendo la loro chat o la chiamata in diretta. Dovrebbero essere in grado di controllare l'utilizzo dell'host durante l'elaborazione della migrazione.

Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.