[...]
attualmente scrive su un log, ma andare a leggersi l'ultimo campo dell´ultima riga fa consumare altrettanto tempo quando il log è lungo
la soluzione potrebbe essere di metterlo in un file che contiene solo
questo e che viene incluso con un include.
Ma quale sarebbe esattamente il problema? Se usi fpm, PHP gira con un suo utente diverso da Apache (www-data). Comunque eviterei l'uso della cartella socks.
Soluzione alternativa al disco: usa memcached.
Il processo aggiorna la entry di memcache, e php la legge. Semplice, lineare, utile anche per altre cose.
Diego
On Thu, 14 Nov 2024, Diego Zuccato wrote:
Ma quale sarebbe esattamente il problema? Se usi fpm, PHP gira con un
suo utente diverso da Apache (www-data). Comunque eviterei l'uso
della cartella socks.
spiego diversamante: ci sono diversi sensori ambientali che inviano
[con dei post in modo asincrono] o vengono interrogati [o con un
processo in cron, oppure richiamati dal processo che riceve i dati] e scrivono i dati su un file di log.
Questo non è particolarmente critico in quanto cresce di circa 20 kB
al giorno.
in modo asincrono una richiesta di una certa pagina web deve ritornare
un contenuto comprendente due valori, che sono per l'appunto il
contenuto degli ultimi due campi dell'ultima riga del log [file CSV].
il tail può funzionare ma non mi pare elegante.
memcached è praticamente un database che puoi alimentare ed interrogare in vari modi.
Se usi un qualsiasi mount tmpfs puoi poi dargli i permessi che ti pare.
Ho un amico che usa un sistema simile per la gestione della sua domotica. Funziona, ma IMO è piuttosto "cervellotico" e scala malissimo, con molte race
condition possibili.
Da quel che hai detto finora, io farei così:
- i sensori mandano le letture con un POST ad un php
- il php salva i valori (eventualmente elaborati) dove serve, p.e. db o memcache
- l'utente interroga un altro php che recupera i dati salvati dal primo
Tutto serializza bene e scala tranquillamente.
Diego
A me così funziona:
root@virt-diego:~# mkdir tmp
root@virt-diego:~# mount -t tmpfs none ./tmp -o size=1m
root@virt-diego:~# df -h
File system Dim. Usati Dispon. Uso% Montato su
[...]
none 1,0M 0 1,0M 0% /root/tmp
Nota che uso -t invece di -F (che mi pare in questo contesto non abbia senso).
Per evitare ritardi lo script di visualizzazione non va a ricalcolare il >dato, ma questo viene fatto da un processo che ogni 5 secondi legge i dati
e se ci sono variazioni rispetto alla lettura precedente ricalcola il >risultato e va a scriverlo su un file.
attualmente scrive su un log, ma andare a leggersi l'ultimo campo >dell´ultima riga fa consumare altrettanto tempo quando il log è lungo
la soluzione potrebbe essere di metterlo in un file che contiene solo
questo e che viene incluso con un include.
Farlo con un file reale rischia a lungo termine di fare un "buco" sul >settore che viene riscritto nel caso peggiore ogni pochi secondi, nel caso >migliore ogni minuto o due
QUesto è vero solo se leggi il file sequenzialmente dall'inizio.(…)
Nella pratica, quelli che il VFS nel SO vede come settori sono in realtà virtualizzati dal firmware del disco,(…)
In pratica, ormai da una decina d'anni se non più, che io sappia il
problema che ti stai ponendo non esiste, se non mi sfugge qualcosa.
On Fri, 15 Nov 2024, Francesco Potortì wrote:
QUesto è vero solo se leggi il file sequenzialmente dall'inizio.(…)
Nella pratica, quelli che il VFS nel SO vede come settori sono in realtà >> virtualizzati dal firmware del disco,(…)
In pratica, ormai da una decina d'anni se non più, che io sappia il
problema che ti stai ponendo non esiste, se non mi sfugge qualcosa.
chiarisco una cosa: il "disco" su cui va a scrivere non penso abbia tanta >cache visto che è una chiavetta USB. per quello mi preoccupavo
chiarisco una cosa: il "disco" su cui va a scrivere non penso abbia tanta cache visto che è una chiavetta USB.
In pratica, ormai da una decina d'anni se non più, che io sappia il problema che ti stai ponendo non esiste, se non mi sfugge qualcosa.
E, tanto per stare tranquilli, usare un *CoW* filesystem, come F2FS,
pensato apposta per quel tipo di supporti?
Così passa ogni paura.
Il giorno ven, 15/11/2024 alle 12.26 +0100, Francesco Potortì ha scritto:
In pratica, ormai da una decina d'anni se non più, che io sappia il problema che ti stai ponendo non esiste, se non mi sfugge qualcosa.
Che io sappia, invece, il problema non è proprio mai esistito.
Né sugli HD [...] né sugli SSD
Il giorno ven, 15/11/2024 alle 12.26 +0100, Francesco Potortì ha scritto:
In pratica, ormai da una decina d'anni se non più, che io sappia il problema che ti stai ponendo non esiste, se non mi sfugge qualcosa.
Che io sappia, invece, il problema non è proprio mai esistito.
Né sugli HD [...] né sugli SSD
Provando a scavare nella mia meoria, sicuramente esisteva sui floppy disk :)
Per gli SSD a me pare di ricordare che il problema esisteva tanti anni fa nelle prime chiavette a livello di settore, e nei primi sistemi più grossi a livello di sezioni del disco fino a una decina di anni fa, quando ancora si leggevano pubblicità orecensioni sui nuovi algoritmi nel firmware o le nuove architetture Nand che evitavano questo problema. Poi, può anche darsi che mi stia sognando tutto, ma è un sogno realistico :)
alla fine credo che il sistema migliore sia di mettere una piccola
directory in tmpfs
...finale da cui estrarre l'ultimo record. Solo se non conosci la lunghezza massima di un record devi leggere dall'inizio.
Per evitare ritardi lo script di visualizzazione non va a ricalcolare ilQUesto è vero solo se leggi il file sequenzialmente dall'inizio. Se il formato ha record di lungheza fissa, puoi accedere direttamente all'ultimo record, se invece la lunghezza è variabile ma conosci la lunghezza massima, puoi accedere alla stringa
dato, ma questo viene fatto da un processo che ogni 5 secondi legge i dati >> e se ci sono variazioni rispetto alla lettura precedente ricalcola il
risultato e va a scriverlo su un file.
attualmente scrive su un log, ma andare a leggersi l'ultimo campo
dell´ultima riga fa consumare altrettanto tempo quando il log è lungo
rigirare come gli pare, e per di più ha una sua cache (i vecchi WD 4TB per esempio hanno una cache di 256MB).la soluzione potrebbe essere di metterlo in un file che contiene soloSe così fosse i dischi si bucherebbero continuamente, anche solo per l'aggiornamento del journal. Nella pratica, quelli che il VFS nel SO vede come settori sono in realtà virtualizzati dal firmware del disco, che in linea di principio se li può
questo e che viene incluso con un include.
Farlo con un file reale rischia a lungo termine di fare un "buco" sul
settore che viene riscritto nel caso peggiore ogni pochi secondi, nel caso >> migliore ogni minuto o due
Inoltre, le scritture su disco viste dal processo sono in realtà virtualizzate dal VFS, che a sua volta usa abbondanti cache, e non le scrive così di frequente. Per esempio sul mio vedo:disco passano almeno 30s.
# sysctl vm.dirty_expire_centisecs vm.dirty_writeback_centisecs vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500
Il che significa che ogni 5s il processo di writeback va a guardare la cache e se ci sono dati non ancora scritti sul disco da più di 30s lancia una scrittura fisica. Il che in pratica significa fra una scrittura fisica e l'altra di quel dato sul
In pratica, ormai da una decina d'anni se non più, che io sappia il problema che ti stai ponendo non esiste, se non mi sfugge qualcosa.
Hummm... il comando tail può leggere l'ultima riga di un file di testo [...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 149:17:54 |
| Calls: | 10,383 |
| Calls today: | 8 |
| Files: | 14,054 |
| D/L today: |
2 files (1,861K bytes) |
| Messages: | 6,417,765 |