Il sito web uccide il disco rigido I / O, come prevenire?

La situazione: ho un server, su cui abbiamo 2-3 progetti. Avviando non molto tempo fa, il server ha iniziato ad appendere (non siamo riusciti a connettersi ad esso con ssh e i client collegati wherevano attendere 20 minuti per dare risultati)

All'inizio di oggi sono riuscito a eseguire gstat mentre era in questo stato e ho visto che rimane al 100% su da0, da0s1 e da0s1f. Non so abbastanza che cosa sono quei ids meen, ma capisco che alcuni processi uccidono solo l'HD bombardandolo con le richieste.

  • Hyper-V - Creazione di un grande disco fisso - EXTREMELY Slow
  • Ubuntu Device-mapper sembra essere invincibile!
  • Installazione di più versioni php e estensioni su freebsd
  • HDD RAID0 domanda
  • Cosa esistono le guide "FreeBSD for Linux Geeks"?
  • Esecuzione di Linux su un solo disco di lettura - ansible?
  • Chiedo alcune proposizioni. Non so come trovare la culpit e non posso impedirlo.

    Ho freebsd sul server.

  • Come installare la versione più recente di g ++ su CentOS
  • Haproxy e nginx rtmp
  • Imansible avviare MySQL? Gestore di pid-file chiude senza aggiornamento
  • Configurare il nome di dominio in CentOS
  • Cant abilita le quote sul file system XFS
  • Imansible iptables-restore a causa di FATAL: Moduli ip_tables non trovati
  • 2 Solutions collect form web for “Il sito web uccide il disco rigido I / O, come prevenire?”

    Se la tua versione di FreeBSD è relativamente moderna, la top ha un'opzione -m che mostra i principali I / O talkers se lo si fornisce con il parametro " io ":

     top -m io 

    In questo caso, userei anche l'opzione -S (per mostrare i processi di sistema, nel caso in cui uno di loro sia il colpevole). Per comportrsi meglio sotto carico, vorrei usare -q (per consentirle di eseguire a una priorità più alta) e -u (per saltare la lettura /etc/passwd , che dovrebbe aiutarlo a caricare più velocemente).

    Dal momento che sta prendendo così tanto tempo per eseguire la parte top , lo direi di visualizzare solo due passaggi della sua output ( -d 2 ) e quindi eseguire in modalità batch ( -b ), quindi verrà automaticamente uscito.

    Il primo momento in cui si esegue in top in questo modo, la sua prima sezione di output mostrerà i conteggi I / O cumulativi per un certo numero di processi per un bel po 'di modi di return (forse dal momento del caricamento, in realtà non sono sicuro di questo). Nella prima visualizzazione è ansible vedere chi sono i tuoi interlocutori più alti nel tempo. Nella seconda visualizzazione, puoi vedere i tuoi interlocutori principali negli ultimi due secondi.

    Quindi, mettendolo insieme e eseguendo una find modo che accada qualche effettivo I / O:

     # top -S -m io -qu -b -d 2 10 last pid: 39560; load averages: 0.28, 0.19, 0.08 up 6+04:02:29 11:28:28 125 processes: 2 running, 104 sleeping, 19 waiting Mem: 96M Active, 668M Inact, 122M Wired, 25M Cache, 104M Buf, 17M Free Swap: 2048M Total, 96K Used, 2048M Free PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 11 0 0 81032823 0 0 0 0 0.00% idle: cpu0 39554 105 129857 556534 74894 0 0 74894 13.62% find 39533 105 443603 614796 0 0 0 0 0.00% sshd 36 0 1793393 0 0 0 0 0 0.00% irq23: vr0 24 0 2377710 2680 0 0 0 0 0.00% irq20: atapci0 50 0 533513 3415672 66 345350 0 345416 62.81% syncer 13 0 78651569 7230 0 0 0 0 0.00% swi4: clock sio 5 0 1911601 20905 0 0 0 0 0.00% g_down 4 0 2368511 12100 0 0 0 0 0.00% g_up 37 0 53308 313 0 0 0 0 0.00% acpi_thermal last pid: 39560; load averages: 0.28, 0.19, 0.08 up 6+04:02:31 11:28:30 125 processes: 2 running, 104 sleeping, 19 waiting CPU: 1.9% user, 0.0% nice, 6.0% system, 2.2% interrupt, 89.9% idle Mem: 96M Active, 671M Inact, 123M Wired, 25M Cache, 104M Buf, 14M Free Swap: 2048M Total, 96K Used, 2048M Free PID UID VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND 11 0 0 1115 0 0 0 0 0.00% idle: cpu0 39554 105 606 651 501 0 0 501 100.00% find 39533 105 616 695 0 0 0 0 0.00% sshd 36 0 1251 0 0 0 0 0 0.00% irq23: vr0 24 0 501 20 0 0 0 0 0.00% irq20: atapci0 50 0 2 2 0 0 0 0 0.00% syncer 13 0 313 3 0 0 0 0 0.00% swi4: clock sio 5 0 501 26 0 0 0 0 0.00% g_down 4 0 501 8 0 0 0 0 0.00% g_up 37 0 0 0 0 0 0 0 0.00% acpi_thermal 

    Una volta che si riduce il process che sta facendo tutto l'I / O, è ansible utilizzare il truss o le porte devel/strace o sysutils/lsof per vedere cosa stanno facendo i processi a disco-affamati. (se il tuo sistema è molto occupato, naturalmente, non sarai in grado di installare facilmente le porte):

    Ad esempio, per vedere quali file e altre risorse utilizza il mio process ntpd :

     # lsof -p 890 ntpd 890 root cwd VDIR 0,93 1024 2 / ntpd 890 root rtd VDIR 0,93 1024 2 / ntpd 890 root txt VREG 0,98 340940 894988 /usr/sbin/ntpd ntpd 890 root txt VREG 0,93 189184 37058 /libexec/ld-elf.so.1 ntpd 890 root txt VREG 0,93 92788 25126 /lib/libm.so.5 ntpd 890 root txt VREG 0,93 60060 25130 /lib/libmd.so.4 ntpd 890 root txt VREG 0,98 16604 730227 /usr/lib/librt.so.1 ntpd 890 root txt VREG 0,93 1423460 25098 /lib/libcrypto.so.5 ntpd 890 root txt VREG 0,93 1068216 24811 /lib/libc.so.7 ntpd 890 root 0u VCHR 0,29 0t0 29 /dev/null ntpd 890 root 1u VCHR 0,29 0t0 29 /dev/null ntpd 890 root 2u VCHR 0,29 0t0 29 /dev/null ntpd 890 root 3u unix 0xc46da680 0t0 ->0xc4595820 ntpd 890 root 5u PIPE 0xc4465244 0 ->0xc446518c ntpd 890 root 20u IPv4 0xc4599190 0t0 UDP *:ntp ntpd 890 root 21u IPv6 0xc4599180 0t0 UDP *:ntp ntpd 890 root 22u IPv4 0xc4599400 0t0 UDP heffalump.prv.tycho.org:ntp ntpd 890 root 23u IPv4 0xc4599220 0t0 UDP ns0.prv.tycho.org:ntp ntpd 890 root 24u IPv4 0xc45995c0 0t0 UDP imap.prv.tycho.org:ntp ntpd 890 root 25u IPv6 0xc4599530 0t0 UDP [fe80:4::1]:ntp ntpd 890 root 26u IPv6 0xc45993b0 0t0 UDP localhost:ntp ntpd 890 root 27u IPv4 0xc4599160 0t0 UDP localhost:ntp ntpd 890 root 28u rte 0xc42939b0 0t0 

    … e che sistema chiama che sta facendo (si noti che questo può essere intenso in termini di risorse):

     # truss -p 890 SIGNAL 17 (SIGSTOP) select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call' SIGNAL 14 (SIGALRM) sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call' select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call' SIGNAL 14 (SIGALRM) sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call' select(29,{20 21 22 23 24 25 26 27 28},0x0,0x0,0x0) ERR#4 'Interrupted system call' SIGNAL 14 (SIGALRM) sigreturn(0xbfbfea10,0xe,0x10003,0xbfbfea10,0x0,0x806aed0) ERR#4 'Interrupted system call' ^C 

    sysutils/strace è simile alla truss , ma è necessario disporre del filesystem /proc :

     # strace -p 890 strace: open("/proc/...", ...): No such file or directory trouble opening proc file # grep ^proc /etc/fstab proc /proc procfs rw,noauto 0 0 # mount /proc # mount | grep /proc procfs on /proc (procfs, local) 

    … e poi functionrà:

     # strace -p 890 Process 890 attached - interrupt to quit --- SIGALRM (Alarm clock: 14) --- --- SIGALRM (Alarm clock: 14) --- syscall_417(0xbfbfea10) = -1 (errno 4) select(29, [?], NULL, NULL, NULL) = -1 EINTR (Interrupted system call) --- SIGALRM (Alarm clock: 14) --- --- SIGALRM (Alarm clock: 14) --- syscall_417(0xbfbfea10) = -1 (errno 4) select(29, [?], NULL, NULL, NULL^C <unfinished ...> Process 890 detached 

    Buona fortuna – farci sapere cosa scopri! Dopo aver identificato i processi, potrei essere in grado di assistere ulteriormente.

    EDIT: Si noti che l'esecuzione di lsof , truss e strace può essere di per sé intensa. Ho fatto alcuni aggiornamenti minori per cercare di ridurre il loro impatto. Inoltre, se un process sta spuntando molti bambini in fretta, puoi wherer dire a truss o a strace di seguire i processi figlio con l'argomento -f .

    Dopo qualche tempo ho trovato il vero problema . Come ho pensato nell'ultimo commento era un problema di mancanza di memory.

    Il culpit era ZEO server per ZODB . Si affidava molto sulla cache del disco di sistema del sistema e si è riaffilata, quando la memory libera era inferiore a 500 MB ha iniziato a rallentare e su 300 MB ha usato solo tanto il disco, che il sistema ha arrestato la risposta e persino alcuni i servizi hanno iniziato a schiacciare (come sshd ).

    Dopo aver modificato la struttura della cache e liberando fino a 2 GB di memory libera, il problema è stato eliminato.

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