Re: Deadlock?
Andrej Sossi <[email protected]> Wed, 19 Oct 2016 11:41:52 +0200
| Newsgroups | gmane.os.freebsd.italian.esperti |
|---|---|
| Organization | DOTCOM S.R.L. |
| Message-ID | <[email protected]> |
Andrea Venturoli il 17. 10. 2016 alle 08:38 ha scritto: > On 10/14/16 16:14, Andrea Venturoli wrote: > = >> P.S. >> Francamente spero sia un problema che mi sono lasciato alle spalle >> passando alla 10.3, ma, se mi dovesse ricapitare, riferiro'. > = > In compenso ora che e' una 10.3 la macchina mi si e' bloccata :(((((: > _ ai ping rispondeva; > _ era impossibile stablire una connessione a qualunque servizio TCP > (SSH, HTTP, ecc...), ma si capiva che in parte funzionava; > _ l'unico modo per uscirne e' stato un riavvio hardware; > _ nei log nulla dal momento del blocco al momento del riavvio. > = > L'impressione e' che si fosse bloccato il sottosistema di storage, > quindi funzionasse tutto cio' che non doveva leggere/scrivere o > interagire in qualche modo coi dischi. > = > La cosa mi era gia' successa in passato su altri server, ma erano i > tempi della 6.x o giu' di li'. > Situazioni del genere le ho viste alcune volte. Ci possono essere pi=F9 cause che danno i sintomi descritti. In linea di massima dipendono tutte dal fatto che c'=E8 un interrupt HW che sta tenendo 'impegnato' il sistema. Comunque non credo sia vero, che non riesci a stabilire una connessione TCP, e solo che il servizio non riesce a rispondere alle richieste. Se provi con telnet vedrai che non ti dice 'connection refuse' o 'timeout' ma rimane appeso per un tempo indefinito. Le possibili cause che ho avuto erano: - disco danneggiato: il disco =E8 leggibile ma ha alcuni cluster danneggiati. Appena cerca di leggerli da errore e l'S.O. ritenta continuamente rendendo impossibile l'accesso al disco agli altri software che per conto loro potrebbero proseguire il loro lavoro. - disco sotto stress: se un software sta lavorando troppo sul disco, senza concludere il lavoro mi ritrovo in una situazione meno grave, ma simile a quella sopra. Un esempio =E8 un MySQL che sta eseguendo una o pi= =F9 query in parallelo con filtri complessi che richiedono a MySQL un lavoro esagerato sul disco. In questa situazione ssh per chiederti la password potrebbe impiegare fino a 15 minuti o pi=F9. - Perdita completa del disco: se il disco =E8 connesso via iSCSI o eSATA = =E8 facile che qualcosa vada storto. In questo caso la reazione del kernel =E8 parecchio imprevedibile. A seconda delle versioni di FreeBSD ho visto comportamenti diversi a seconda della versione. Dal freez completo a un funzionamento della shell fino alla prima richiesta di accesso al disco perso, etc. Cosa esattamente succede nella 10.3 non so (ancora) e spero di non scoprirlo personalmente. Le mie sono ovviamente ipotesi. Spero di averti dato qualche spunto. Se ti succede spesso, ti consiglio di aprirti immediatamente alcune shell e tenerti aperti alcuno monitoraggi del sistema tipo: iostat -xw 1 netstat -w 1 (o meglio netstat -w 1 -i em0) top -m io top E cerca di capite quale componente =E8 al limite o se si blocca tutto o ... -- = Cordiali saluti Sossi Andrej ------------------------- DOTCOM Information technology Via Machiavelli, 28 34132 - Trieste (TS) Italy tel: +39 040 9828090 fax: +39 040 0641954 E-mail: [email protected] ---------------------------- Ai sensi del D.lgs n. 196 del 30.06.03 (Codice Privacy) si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di eliminarlo senza copiarlo e di non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie This message, for the D.lgs n. 196 / 30.06.03 (Privacy Code), may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. _______________________________________________ Esperti mailing list [email protected] http://mailman.gufi.org/mailman/listinfo/esperti