Quanti thread dovrebbero accedere al file system contemporaneamente?

Question

Quanti thread dovrebbero accedere al file system contemporaneamente?

#1 da (2 voti)
#2 da (1 voti)
#3 da (0 voti)

7

Abbiamo un modulo in un'applicazione che memorizza i dati in più file e directory multilivello e li accede da più thread (sia in lettura che in scrittura). La struttura della directory è basata su un valore hash diviso, come:

b1/94/6a/92/a.txt
b1/94/6a/ee/a.txt
a1/0e/db/bb/b.txt
...

Se un chiamante rimuove un file, il modulo elimina immediatamente le directory vuote.

Quanto dovrebbe essere il livello di concorrenza del modulo? Vale la pena creare e cancellare cartelle da più thread contemporaneamente? I filesystem possono gestirli efficacemente?

Vale la pena utilizzare un modulo multi-thread? (Sarebbe molto più facile scrivere uno thread singolo.)

(L'applicazione è scritta in Java e funziona principalmente su Windows, NTFS, non-SSD ma sono interessato anche ad altri sistemi operativi e file se ci sono differenze.)

java file-systems concurrency multithreading

posta usr95 03.07.2013 - 22:54

fonte

3 risposte

Leggi altre domande sui tag java file-systems concurrency multithreading

Come convertire un repository di Bazaar in un repository GIT? Procedure ottimali accettate per setup.py di un progetto biforcuto

score 2 · Answer 1

Ovviamente qualsiasi sistema operativo gestirà più richieste, ma anche quando chiedi un file system basato su supporti fisici con tempi di ricerca per fare più di una cosa in una volta, le tue prestazioni peggioreranno progressivamente. Nella mia esperienza è meglio sul lato delle prestazioni avere solo un thread che accoda le richieste e poi le passa al sistema operativo in modo sequenziale.

Un'opzione potrebbe essere quella di separare le operazioni di scollegamento e mantenerle fino a quando non rileva un intervallo di tempo in cui si verificano poche operazioni di dati, quindi elimina quelle directory per mantenere le richieste di dati il più rapidamente possibile e la tua modo.

Ovviamente è una soluzione semplice, ma penso che sia semplice fino a quando qualche altro requisito impone un'ottimizzazione o riorganizzazione.

score 1 · Answer 2

Dovresti profilare la tua app per essere sicuro. Dipende da come usi i tuoi file potrebbe essere cattivo o molto buono. Se leggi solo & scrivere in una manciata di file, quei file saranno memorizzati nella cache e i loro blocchi saranno bufferizzati. Potrebbe non toccare il disco per un po 'di tempo.

Se crei molti file e amp; directory e rimuoverli così velocemente come li crei, quindi sicuramente cestinerai la cache e i buffer. Non importa quanti thread lo stanno facendo.

Se hai più processi (non thread), otterrai una quota maggiore del tempo del file system.

Avere una discussione per raccogliere le richieste di lettura / scrittura dei file da altri thread è solo la duplicazione del lavoro del sistema operativo e solitamente il SO può pianificare e riordinare quelle richieste meglio di quello con cui si desidera investire tempo.

score 0 · Answer 3

Umm, non sono sicuro di cosa stai tentando di fare qui, ma sei sicuro che le tue esigenze non sarebbero servite meglio usando un database piuttosto che accedere direttamente al filesystem. Un database gestirà più richieste simultanee per te e proteggerà le condizioni di gara.