Posso ricevere gli allarmi fcntl e Perl per cooperare?

Question

Sono su linux, nfs, con più macchine coinvolte.

Sto provando a utilizzare fcntl per implementare il blocco dei file. Stavo usando il gregge fino a quando ho scoperto che funziona solo tra processi sulla stessa macchina.

Ora quando chiamo fcntl con F_SETLKW, gli allarmi perl (per aggiungere un timeout) non funzionano come prima. Questo normalmente sarebbe ok, ma ctrl-c non funziona davvero neanche.

Quello che credo stia accadendo, è che fcntl sta solo controllando i segnali ogni 30 secondi circa. L'allarme ritorna alla fine. Il ctrl-c viene catturato, ... eventualmente.

C'è qualcosa che posso fare per regolare la frequenza con cui fcntl controlla questi segnali?

Answer 1

Non sono assolutamente esperto in materia, ma la mia conoscenza è che fcntl, come hai anche affermato, non funzionerà nel tuo caso. le serrature di consulenza fcntl hanno senso solo all'interno della stessa macchina.

Quindi dimenticami se questo è off-topic. Ho usato File::NFSLock per risolvere il problema di cache storms/dogpile/stampeding. C'erano più server di applicazioni che leggevano e scrivevano file di cache su un volume NFS (idea non molto buona, ma era quello che avevamo iniziato).

I subclassed/wrapped File :: NFSLock per modificare il relativo comportamento. In particolare mi serviva:

• persistenti serrature, che non vanno via quando un oggetto File :: nfslock esce dallo scope. Usando regolare File :: NFSLock, il tuo lucchetto sparirà quando l'oggetto non sarà più incluso. Questo non era quello di cui avevo bisogno.
• che i file di blocco effettivo contengono anche il nome della macchina che ha acquisito il blocco. L'id del processo non è chiaramente sufficiente per decidere se un processo è terminato, quindi posso rubare il lockfile in sicurezza. Così ho modificato il codice per scrivere lockfiles come machine:pid anziché solo pid.

Questo ha funzionato meravigliosamente per un paio di anni.

Fino a quando il volume delle richieste ha registrato un aumento di 10 volte. Cioè, il mese scorso ho iniziato a sperimentare i primi problemi in cui un file cache molto occupato veniva scritto da due backend allo allo stesso tempo, lasciando blocchi morti. Questo è successo per me quando abbiamo raggiunto circa 9-10 milioni di pagine viste al giorno, solo per darti un'idea.

Il file di cache rotta finale sembrava:

<!-- START OF CACHE FILE BY BACKEND b1 --> 
... cache file contents ... 
<!-- END OF CACHE FILE BY BACKEND b1 --> 
... more cache file contents ... wtf ... 
<!-- END OF CACHE FILE BY BACKEND b2 --> 

Questo può avvenire solo se due backend scrivono allo stesso file nello stesso momento ... Non è ancora chiaro se questo problema è causato dal file: : NFSLock + le nostre mod o alcuni bug nell'applicazione.

In conclusione, se la tua app non è molto trafficata e trafficata, allora vai su File :: NFSLock, penso che sia la soluzione migliore. Sei sicuro di voler ancora usare NFS?