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