Tworzenie/zapis pliku w jednym kawałku

Witam serdecznie
Delphi - Windows Serwer 2003 / 2008 / 2012

Mam aplikację, która między innymi w ciągu całego dnia tworzy plik z podsumowaniem swojej pracy (wielkość pliku to ~300 Mb) w tym samym czasie rejestruje w innych plikach różne parametry aktualnych zdarzeń. Takich aplikacji pracuje na jednej maszynie od 6 do 11 (maszyna do Serwer HP DL380).
Problem z którym nie wiem jak się uporać to tworzenie się tego "wielkiego" pliku w taki sposób , że po utworzeniu na dysku plik ten fizycznie składa się bardzo wielu części (od 500 do 180000 - takie wartości zarejestrowałem). Taka sytuacja powoduje bardzo mocny spadek wydajności operacji dyskowych szczególnie gdy na koniec kwartału musimy szybko przeanalizować pliki z 3 miesięcy z np 6 programów ( 6 prog. x 90 dni/plików x ~50000 fragmentów = dużo czasu ).

Moje pytanie jest następujące :
Czy istnieje jakiś sposób by zmusić Windowsa aby zapisał ten plik w jednym ciągu na dysku ?
lub lepiej by wymusić zarezerwowanie odpowiedniej ilości miejsce dla tego pliku na dysku już w momencie jego tworzenia ?

Próbowałem tworzć ten plik od razu w odpowiedniej wielkości poprzez zapis blokami 4096b (pustymi - same znaki 0)
Efekt końcowy nie był lepszy niż przy normalnej procedurze.
fragment tego kodu :

            Rewrite(plik,1);
            Poz1:=Org_File_Size div 4096;
            repeat
               {$I-}
                 BlockWrite(plik,File_Bufor0,4096,Poz2);
               {$I+}
               Dec(Poz1);
            until Poz1=0;

Z poważaniem Tomasz B

TBWhite napisał(a):

Czy istnieje jakiś sposób by zmusić Windowsa aby zapisał ten plik w jednym ciągu na dysku ?

Musiałbyś zaimplementować mechanizm podobny do tych istniejących w programach do defragmentacji dysku. Tak więc możliwość istnieje, ale nie tanim kosztem. Choć zapewne już ktoś taki mechanizm zrobił, więc dobrze by było przeszukać sieć pod kątem jakiejś biblioteki.

TBWhite napisał(a):

lub lepiej by wymusić zarezerwowanie odpowiedniej ilości miejsce dla tego pliku na dysku już w momencie jego tworzenia ?

Oczywiście – jest to nawet bardzo popularna technika. Przykład:

var
  Stream: TFileStream;
begin
  Stream := TFileStream.Create('file.dat', fmCreate or fmOpenWrite);
  try
    // rezerwacja przestrzeni – 300MiB
    Stream.Size := 1024 * 1024 * 300;
    // instrukcje uzupełniające plik
  finally
    Stream.Free;
  end;

Przy czym najpierw przydałoby się upewnić, że na dysku faktycznie znajduje się tyle wolnej przestrzeni, ew. zabezpieczyć kod na wypadek zaistnienia wyjątku.

rozmieszczenie danych pliku na dysku zależy tylko i wyłącznie od systemu. Aplikacja zapisuje przez uchwyt (handle) pliku, a fizycznym zapisem danych (pliku) na dysku zarządza system operacyjny, sterownik dysku itp ....

jak napisał @grzegorz_so - fizycznie zapisuje system. Musiał byś go obejść. Pierwszy problem to taki, że musisz grzebać bezpośrednio w FAT - chodzi o tablice rozmieszczenia plików na dysku a nie nazwę systemu jako takiego (NTFS też ma coś takiego), a że windows obsługuje kilka systemów (co najmniej FAT32 i NTFS) to już jest więcej roboty. Po drugie musiał byś być pewnym, że masz blok ciągły na dysku o wymaganym rozmiarze.

Co do "rezerwowania" od razu wymaganego rozmiaru to nic nie zmieni bo to i tak system decyduje gdzie zapisać. Z tego co pamiętam to przy FAT było to robione tak, że system znajdował pierwszy wolny sektor, zapisywał tam a następnie w kolejnych sektorach o ile były wolne aż do sektora zajętego. W każdym ostatnim sektorze bloku, na końcu zapisywany jest wskaźnik, w którym sektorze są kolejne dane i tak aż do zapisania całego pliku. Jak widzisz to czy plik jest zapisywany "na raz" czy po kawałku nie ma znaczenia dla jego "rozczłonkowania". Jedynie tyle, że jak zapisujesz w jednostce czasu kilka plików po kawałku to te kawałki mogą się wzajemnie przeplatać na dysku.

Wg mnie należało by zacząć rozwiązywanie problemu od cyklicznego defragmentowania dysku. Są programy (zarówno płatne jak i darmowe), które po instalacji defragmentują dysk np. podczas bezczynności lub w określonych godzinach. Uważam, że jest to rozwiązanie wystarczające i przede wszystkim łatwe w implementacji i utrzymaniu. Kiedyś używałem Diskeeper`a (obecnie mam SDD i jego jako takiego nie defragmentuje się) i sprawdzał się o ile miał chwilę na popracowanie - pracował głównie wtedy jeśli wykrył bezczynność na kompie.

Reasumując ściągnij coś darmowego albo jakąś wersję testową softu do defragmentacji, zainstaluj, odpal ciągłą optymalizację plus np. raz w tygodniu pełny defrag i zobacz czy efekty Cię zadowolą.

Pomijam oczywistą oczywistość jaką jest osobna partycja (nie musi być to dysk ale może być) przeznaczoną tylko i wyłącznie na te dane.

Witam serdecznie

Dzięki za zainteresowanie tematem. Postaram się jeszcze rozszerzyć opis działania systemu by łatwiej było złapać w czym problem.
System jak wspominałem składa się z kilku (6-11) aplikacji , które to aplikacje mogą uruchomić w sobie dodatkowe wątki pracujące z dyskiem.
Każda aplikacja w ciągu jednej sekundy odczytuje/zapisuje z około 60 plików danych. Dane są dopisywane do plików na ich końcu , wszystkich plików jest około 2400 i z zawsze o północy jest tworzony nowy komplet ok 1200 plików. Dodatkowo zapisuje i odczytuje dane z 20 plików status mających stałą długość (struktura podobna do plików INI) jest ich razem około 3600 i jest to ilość w miarę stała. Oprócz tego w odpowiedzi na określone zdarzenia (żądania SQL , aktywność użytkowników końcowych , awarie sprzętowe monitorowanych systemów) program uruchamia wątki dodatkowe, które tworzą serie kilku plików tymczasowych (5-6 plików na jedno zdarzenie) , a na zakończenie swojej pracy wątki usuwają te pliki. Przykładowo jeśli na maszynie takich aplikacji pracuje np 6 to tylko jedna ma takie duże obciążenie (apka zbiorcza) pozostałe pracują w przybliżeniu z 30% podanych wcześniej wartości.

Pomysł ze strumieniem postaram się sprawdzić - myślę że przy nowym pustym dysku się sprawdzi i spowoduje dużo wolniejsze "unieruchamianie" systemu - dzięki.

Pomysł z defragmentatorami też przyszedł mi do głowy i wcześniej go spróbowałem ale w praniu okazało się, że:
Na 6 sprawdzonych programów tylko dwa dały radę przedrzeć się przez etap Analizy dysku (pozostał wykładały się z komunikatami typu , out of memory - 16GB RAM-u to dla nich za mało ?). Dwa, które dały radę w następnym etapie pracy poinformowały że spodziewany czas defragmentacji dysku to ~37.400 dni ( ! 102 lata ! ) w jednym i ~114.000 dni ( ! 312 lat ! )w przypadku drugiego programu. Zatrzymałem pracę tego kompa i przeniosłem prawie połowę danych z dysku na dysk zapasowy (external) - trwało to 7 dni ( to było coś koło 260 GB i 2.750.000 plików - zarejestrowane transfery na poziomie od 60 do 400 kb/s). Ponownie zapuściłem defragmentatory (tylko te dwa ca dały radę wcześniej - oczywiście nie razem) i efekt był taki: spodziewany czas ~13400 dni i ~43000 dni , ale tu ciekawostka jeden z programów podał tez informację, że największy dostępny ciągły blok pusty ma wielkość 786432b , wielkość średnia pliku to 260 kb, średnia ilość fragmentów na plik to ~6300, całkowita ilość plików ~846.000 sztuk.
Wiem dlaczego całość tak spowalnia i jest nadal wolna mimo dużej ilości "wolnego" par excellence ( uwielbiam ten zwrot) miejsca na dysku. To kwestia fragmentacji plików. Fragmentacja ta trochę paradoksalnie zwiększa się wraz z usuwaniem starych danych z dysku.

Pytanie jak temu zapobiec ?
- cały czas mieć uruchomiony defragmentator ? (są takie co mają taką opcję ale tam ustawia się , że mają pracować gdy wykryją Idle time, a u mnie system spowalnia tylko w godzinach 22:00- 02:00 i obciążenie spada do 30% podstawowego),
- dodać defragmentację do harmonogramu systemu ? ( programy żądają za pierwszym razem pełnej defragmentacji - nie do przyjęcia ze względu na czas trwania , lub nie żądają ale wtedy analiza trwa 7h - co nie jest dopuszczalne bo mam tylko 4h okienka o obniżonym obciążeniu)
- program powinien sam pilnować by pliki były tworzone od razu z maksymalną wielkością - to jest do wykonania
ale powinien też na koniec dnia potrafić przenieść przesunąć plik na dysku by był w jednym kawałku - tu nie znam sposobu jak to wykonać.
- pliki tymczasowe dla wątków dodatkowych ( oceniłem że co dzień powstaje ich ok 360 i tyle jest kasowanych a wielkości tych plików są pomiędzy 12.8Kb a 330Mb) należało by tworzyć na jakimś wirtualnym dysku (może RAM-dysk) albo jakiś plik wymiany o stałe wielkości

Może jakieś inne lepsze propozycje ?

Ps.
Ciekawe w jaki sposób załatwiają to producenci defragmentatorów - bo chyba nie odwołują się do dysków nisko poziomowo na poziomie sprzętu (bo by musieli znać wszystkie typy dysków) , a z drugiej strony Microsoft chyba nie pozwala na taki dostęp na poziomie sprzętu ? To musi jakoś przechodzić przez sterownik dysku (kontroler IDE ,ATA, SATA, SAS) czyli powinno być chyba jakieś Win API do tego służące ? Może ktoś coś takiego robił albo chociaż widział to i wie jak to może się nazywać po "hamerykańsku" ?

Dodam tylko , że pojedyncza aplikacja systemu była projektowana na obsługę max 256 źródeł danych (optymalnie =<128) a aktualnie każda z nich obsługuje ponad 400 , a ta zbiorcza nawet i 1200 źródeł danych.

Dodam tylko w ramach wyjaśnienia , że dysk na którym zbierane są dane to RAID 1+0 (sprzętowy P401 HP) na napędach IBM SAS całkowita pojemność ~440 GB. Jest tylko jedna partycja cała do dyspozycji wspomnianych aplikacji.

może się zastanów nad bazą danych albo nad mniejszą ilością plików. Wątpię aby dało się ogarnąć jakoś sensownie takie ilości pliczków, które mają średnio po 100kb
Wielowątkowość nie będzie stanowić problemu. Natomiast co do ilości insertów na sekundę to trzeba przetestować.

Witam
Tam jest baza danych SQL (Microsoftu) i dane zbierane przez system trafiają ostatecznie do tej bazy - jednak jakość danych ich ilość i zawartość (nadmiarowość informacji w danych surowych to jakieś 8x)oraz zawodność transmisji powodują że przed wstrzyknięciem do bazy aplikacja musi je odpowiednio przygotować. Baza do dyspozycji dostaje średnio co 4 godziny komplet 1200 plików z wyselekcjonowanymi odpowiednio sformatowanymi i sprawdzonymi danymi. Pliki mają stałą długość i nie są kasowane, a jedynie modyfikowane (data utworzenia najstarszych - to początek pracy systemu 2009 r - same pliki nie są pofragmentowane - 0 fragmentów :) ). Ich transmisja do SQL-a idzie jak na razie bez najmniejszego zarzutu i tak było zawsze (baza SQL znajduje się na fizycznie zupełnie innym dysku - też RAID 1+0 2 x IBM SAS 74GB). Problemem jest czas dostępu do innych plików (szczególnie wątki dodatkowe potrafią raportować czas oczekiwania na dostęp do pliku na poziomie nawet 18-20 s. !?! ).

no to zamieńcie tego RAIDa na jeden dysk SSD i problem powinien się rozwiązać (choćby testowo na np. tydzień) - SSD 500GB to koszt około 700-1000zł. Trzeba mieć tylko na uwadze, że w takiej pracy ten SSD wytrzyma krócej niż HDD.

Nie wiem jaki jest sposób zbierania i zapisywania tych danych - czy po każdym przychodzącym "pakiecie" jest on od razu zapisywany? Jeśli tak to myślę, że można by spróbować buforować te "próbki" i np. zapisywać całymi paczkami co 1 - 5 minut (w grę wchodzi to jak często zdarza się "przypadkowy" reset i ile danych można stracić)

w sumie to samsung pro wytrzymuje 9PB zapisu więc nie wiem czy klasyczny HDD wytrzyma więcej (a na pewno będzie wolniej)

http://www.guru3d.com/news-story/endurance-test-of-samsung-850-pro-comes-to-an-end-after-9100tb-of-writes.html

Jak ja uwielbiam, gdy ktoś wynajduje koło na nowo. Wymyślono bazy danych, nawet plikowy sqlite, nie wymagający żadnej instalacji. Ale nie, będę pchał dane do pliku i potem zastanawiał się, jak go optymalnie parsować. Kijj tam, że sqlite już to zaimplementował, ja chcę sam

Krzywy Programista napisał(a):

Jak ja uwielbiam, gdy ktoś wynajduje koło na nowo. Wymyślono bazy danych, nawet plikowy sqlite, nie wymagający żadnej instalacji. Ale nie, będę pchał dane do pliku i potem zastanawiał się, jak go optymalnie parsować. Kijj tam, że sqlite już to zaimplementował, ja chcę sam

Jak ja uwielbiam takich mądralińskich - co to do wszystkiego stosują bazy SQL - a potem wszystko działa tak jak działa...super tylko użytkownicy są niezadowoleni.

• system ten istnieje od 2009 roku i jako taki sprawdzał się do tej pory wyśmienicie. Od czterech lat niestety (albo na szczęście) ilość obsługiwanych punktów i klientów zaczęła rosnąc bardzo szybko (jak wspominałem system był zaprojektowany na max 256 źródeł danych i ok 100 klientów wtedy jeszcze bez serwera WWW) w związku z tym system wymaga do sprawnej pracy wyczyszczenia historii i plików (wymieniamy HDD) mniej więcej co dwa lata ale okres ten radykalnie zaczął się skracać i z tego powodu pojawiło się moje zapytanie.

• wykonaliśmy próbę zaimplementowania rozwiązania opartego praktycznie tylko o bazę SQL (dane przychodzące z czujników były wbijane bezpośrednio do bazy) - działało to całkiem nieźle przez pierwsze dwa miesiące po czym baza przestawała dawać radę i wydajność systemu spadała do nieakceptowalnej ( dodatkowo padała obsługa WWW). Rozwiązanie to działa sprawnie, ale trzeba co dwa miesiące resetować bazę - a klienci mają mieć zagwarantowany dostęp do danych z ostatnich 3 lub 5 lat w zależności od umowy i to powoduje dodatkowe komplikacje oraz dodatkową masę pracy, dla osób które opiekują się tą częścią systemu

• analiza danych w tym systemie wymaga nie tylko kontroli zawartości przychodzących danych ale również parametrów czasowych jak i przesunięć czasowych danych z czujnika względem siebie jaki i pozostałych czujników - wymagana jest bieżąca korekta czasów rejestratorów i wszystkich jednostek pomiarowych. System ma ograniczony czas na reakcję na pewne charakterystyczne ustawienia danych , czas ten to ok 12s. taki rozmiar ma okno czasowe w którym czujnik "widzi" serwer i vice versa (w czasie tym należ uwzględnić czas transmisji z i do czujnika - to może być 2-8 s w każdą stronę) i jest to najbardziej krytyczna część analizy i pracy systemu - nie może zawodzić w żadnej sytuacji nawet przeciążenia systemu serwera czy przerywania "szarpania" transmisji danych z czujników.

I ta część jest zaimplementowana jako niezależne oprogramowanie , zoptymalizowane funkcje odbioru i komunikacji , algorytmy analizy danych i wiele części tego oprogramowania nie jest naszą własnością i nie możemy ich użyć we własnej aplikacji ani zmodyfikować w istniejącej aplikacji.

Podsumowując problem można rozwiązać:

1. za pomocą dysków SSD

   • plusy :
     - brak jakiejkolwiek ingerencji w oprogramowanie,
     - łatwość wykonania zmiany,
     - czas wykonania zmiany.
   • minusy :
     - trwałość kontra cena.

2. permanentnej defragmentacji dysków

   • plusy :
     - brak jakiejkolwiek ingerencji w oprogramowanie,
     - łatwy dostęp do gotowych aplikacji
   • minusy :
     - brak dobrej dokumentacji do tworzenia własnych rozwiązań
     - długi czas implementacji
     - dodatkowe obciążenie serwera
     brak pewności pełnego rozwiązania problemu

3. przeprogramowanie i przebudowanie systemu na czysto bazodanowy

   • plusy :
     - podatność na zmiany i skalowalność systemu praktycznie nieograniczona
     - dobrze znane i sprawdzone sposoby obsługi.
   • minusy :
     - wysokie koszty (zakup licencji na algorytmy)
     - długi czas implementacji,
     - spore koszty dodatkowe,
     - brak pewności pełnego rozwiązania problemu.

@TBWhite: wymiana dysku na SSD niczego nie zmieni w dłuższej perspektywie.

Przez pierwsze miesiące będzie czuć różnicę związaną z wysoką wydajnością tych dysków, jednak z czasem wydajność spadnie i stopniowo będzie się pogarszać. Nie ze względu na specyfikę SSD, a przez wszędobylską fragmentację danych. Absolutnie nie jest normalnym fakt zapisu pliku o wadze 300MB w 180 tysiącach fragmentów – nie dziwię się, że system ledwo zipie.

Według mnie wąskim gardłem jest tutaj fragmentacja danych – logiczne, że im więcej fragmentów, tym wolniejszy odczyt i zapis. Dysk musi mieć dużo wolnej przestrzeni na nowe dane, a ich zawartość musi być regularnie ”sprzątana”.

Rozwiązań tego problemu jest kilka i w sumie sensownym jest przebudowa systemu na w pełni bazodanowy – co niestety, ale wiązać się będzie z wysokimi kosztami i sporym nakładem pracy. Tu musisz się zastanowić czy dacie radę udźwignąć tak dużą zmianę.

Rozwiązaniem pozwalającym utrzymać bieżącą wersję systemu jest defragmentator – tanie i wygodne. Narzędzi tego typu jest sporo, więc jest w czym wybierać. Defragmentator potrzebny jest na każdej jednostce przechowującej dane oraz wymagane jest sprzątanie częste i regularne (im częstsza defragmentacja, tym krótsza, bo mniej danych zdąży się podzielić). Zadanie układania danych ustawić w taki sposób, aby nie wtrącało się w nieodpowiednim momencie (podczas gdy system korzysta z danych), a także aby pokrywało się z przybywaniem nowych plików.

Jednak aby defragmentator działał sprawnie i sprzątał porządnie, na dysku musi być dużo wolnej przestrzeni. Jak pustej przestrzeni zacznie brakować to defragmentator nic nie zdziała.

A gdyby wydzielić specjalną partycję i na niej umieścić tylko plik z danymi. Wiem że kiedyś takie przenoszenie systemowego pliku wymiany poprawiało wydajność nie wiem jednak czy to by coś dało w tym przypadku. Mogę się mylić ale myślę że jeden plik na dysku zlikwidowałoby problem fragmentacji.

@furious programming:
na dyskach SSD fragmentacja plików nie jest problemem i w bardzo niewielkim stopniu spowalnia zapis i odczyt , i właśnie tym tkwi ich przewaga nad tradycyjnymi dyskami talerzowymi ponieważ czas dostępu do danych jest niemal taki sam (i bliski zeru) dla każdej jednostki danych na dysku. Jedyne różnice w czasie dostępu mogą wynikać z algorytmów wyliczenia gdzie znajdują się właściwe dane, ale to są pomijalne czasy..

@grzegorz_so: ogólnie tak, jednak nie jestem pewien czasu dostępu do pliku podzielonego na 180 tys. fragmentów, dlatego uznałem wymianę dysków za rozwiązanie połowiczne. Poza tym, kupno i wymiana dysków jest dużo droższe niż zakup licencji profesjonalnego defragmentatora. ;)

TBWhite napisał(a):

• wykonaliśmy próbę zaimplementowania rozwiązania opartego praktycznie tylko o bazę SQL (dane przychodzące z czujników były wbijane bezpośrednio do bazy) - działało to całkiem nieźle przez pierwsze dwa miesiące po czym baza przestawała dawać radę i wydajność systemu spadała do nieakceptowalnej ( dodatkowo padała obsługa WWW). Rozwiązanie to działa sprawnie, ale trzeba co dwa miesiące resetować bazę - a klienci mają mieć zagwarantowany dostęp do danych z ostatnich 3 lub 5 lat w zależności od umowy i to powoduje dodatkowe komplikacje oraz dodatkową masę pracy, dla osób które opiekują się tą częścią systemu

Z ciekawości jaka była wielkość bazy, ile rekordów. Ile tabel. Jakie czasy wykonywania zapytań. Bo wydaje mi się, że po prostu baza była źle zaprojektowana. Sam miałem do czynienia z takimi rzeczami. Drobna poprawa w postaci dodania kilku indeksów, zmiana zapytań spowodowała wielokrotne przyspieszenie działania systemu.

U mnie potrafi być na 0.5h około 300GB :) I jeszcze muszę z nich obliczyć obraz, ale na szczęście tylko chwilowe skoki aczkolwiek możliwe wielokrotnie podczas dnia roboczego ;)

Nie wiem jak autor rozwiązał konkurowanie aplikacji o zasoby ?
**Jak 6 różnych procesów próbuje zapisac/odczytac jednocześnie to nie jest 6 razy wolniej tylko 66 razy ;) **
Ja nie dopuszczał bym do sytuacji ze dwóch albo więcej sie bije o dysk
Obserwował bym obciążenie dysku , na ile jets obciazony a na ile procesy sie blokuja

SqLite nie jest aż taki szybko , ale go używam i sobie chwale z powodu prostej implementacji tylko trzeba sobie oszacować czy nam sie opłaci , nie znam projektu wiec nie ocenie, mi czasami sie kalkuluje a czasami trzymam pliki RAW

Jak komuś nie pasuje system plików to zawsze można sektor po sektorze , ale ja bym nie oczekiwał że bedzie skok wydajności. Da sie to zrobić (bo tez tak uzywam w jednym, projekcie) ale specyfika urzadzenia wymagała takiego podejscia ,** raczje nie kombinował bym az tak bardzo tylko szukał waskiego gardła , prawdziwego !!!**

Mr.YaHooo napisał(a):

TBWhite napisał(a):

• wykonaliśmy próbę zaimplementowania rozwiązania opartego praktycznie tylko o bazę SQL (dane przychodzące z czujników były wbijane bezpośrednio do bazy) - działało to całkiem nieźle przez pierwsze dwa miesiące po czym baza przestawała dawać radę i wydajność systemu spadała do nieakceptowalnej ( dodatkowo padała obsługa WWW). Rozwiązanie to działa sprawnie, ale trzeba co dwa miesiące resetować bazę - a klienci mają mieć zagwarantowany dostęp do danych z ostatnich 3 lub 5 lat w zależności od umowy i to powoduje dodatkowe komplikacje oraz dodatkową masę pracy, dla osób które opiekują się tą częścią systemu

Z ciekawości jaka była wielkość bazy, ile rekordów. Ile tabel. Jakie czasy wykonywania zapytań. Bo wydaje mi się, że po prostu baza była źle zaprojektowana. Sam miałem do czynienia z takimi rzeczami. Drobna poprawa w postaci dodania kilku indeksów, zmiana zapytań spowodowała wielokrotne przyspieszenie działania systemu.

Ja tez ciekawy !
I tutaj autor watku napisał że baza danych działała OK ale z nieznanych powodów przestawała działać po jakimś czasie :)
To zamiast zrozumieć problem i go rozwiązać to zostało pogrzebane :(
Kto to projektował ta bazę danych?

Adamek Adam napisał(a):

I tutaj autor watku napisał że baza danych działała OK […]

No nie, pytacz nie ma bazy danych – ma luźne pliki, imitujące bazę danych. ;)

[…] ale z nieznanych powodów przestawała działać po jakimś czasie :)

Zostało to już wyjaśnione – wąskim gardłem jest używanie dysków talerzowych, fragmentacja dużych plików sięgająca nawet 160.000 fragmentów oraz brak ich defragmentowania.

To zamiast zrozumieć problem i go rozwiązać to zostało pogrzebane :(

Problem już dawno został zrozumiany i jednym z rozwiązań jest wymiana dysków na SSD, które nie są wrażliwe na fragmentację. Drugim rozwiązaniem jest przeprojektowanie całego systemu, tak aby korzystał z profesjonalnego systemu bazodanowego. Trzecim jest instalacja profesjonalnego oprogramowania do defragmentacji plików i ustawienie regularnej defragmentacji, aby nie dopuścić do podziału plików na tysiące kawałków.

Każde rozwiązanie ma swoje plusy i minusy – każdy mający ten sam problem powinien wybrać takie, na które pozwoli mu budżet i czas implementacji.

Jeszcze raz żebym dobrze zrozumiał problem.
Kilka aplikacji 6-11 zbiera informacje z jakichś czujników i jedynie dopisuje nowe dane (niczego nie kasuje).

Każda aplikacja w ciągu jednej sekundy odczytuje/zapisuje z około 60 plików danych.

Czy te 60 plików są z określonego okresu czasu np. z ostatniej doby czy potrzebujesz dostępu do danych archiwalnych np. z ost. 2 lat?

wszystkich plików jest około 2400 i z zawsze o północy jest tworzony nowy komplet ok 1200 plików

rozumiem, że o tej północy jest jakby reset systemu i wcześniejsze dane nie są potrzebne do dalszej analizy?

Jeśli jest tak jak mówię to na twoim miejscu zrobiłbym tak, że serwer aplikacji tylko odbiera dane z czujników i je zapisuje do bazy (z ost 24 lub 48h). Jak już pisałeś macie taki system i się sprawdzał. Natomiast inne serwery poboczne w miarę możliwości tylko ściągają już te dane, kasują z serwera aplikacji i mielą je na swój sposób - zaleta to odciążona krytyczna część systemu, poboczne serwery mogą wolno archiwizować, przetwarzać i udostępniać dane końcowemu klientowi, nawet jak tam się coś zawiesi to nowe dane będą spływać na odseparowanej bazie.