Eliminazione di file molto grandi senza blocco del server web


11

Nel mio server Web (Apache è in esecuzione, Linux CentOS), c'è un file di registro molto grande ( 50 Gbyte ). Questo server Web ha alcuni servizi Web in produzione.

Quando ho provato a eliminare il file di registro, il server Web non ha ricevuto risposta per circa 10 secondi. (Tempo di esaurimento servizio).

rm -f monthly.log

Esiste un modo per eliminare questo file di grandi dimensioni senza il blocco di Apache?

Risposte:


23

Ruotalo prima tramite logrotate, usando una configurazione come questa:

/path/to/the/log {
    missingok
    notifempty
    sharedscripts
    daily   
    rotate 7
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
    endscript
    compress
}

quindi creare un processo cron a mezzanotte per eliminare il file ruotato:

30 2 * * * nice -n 19 ionice -c2 -n7 rm -f /path/to/the/log/file.1

Puoi spiegare cosa significa / cosa fa?
mowwwalker,

1
stai "curando" e "ionizzando" la cancellazione. Nice usava probabilmente per prevenire qualsiasi sovraccarico della CPU, ma qui il più importante è ionice, dove in realtà stai dicendo allo scheduler di eliminare il file con una priorità più bassa. -c è per la classe, dove 1 è in tempo reale, 2 normale e 3 inattivo. All'interno della classe 2, hai da 0 a 7 (IRRC) dove 7 è il più basso. Se questo crea ancora problemi, eseguilo con 'ionice -c3' e dovrebbe andare bene.
Golan,

5

Per una più rapida cancellazione di file di grandi dimensioni, è possibile utilizzare il truncatecomando - Dire per ridurlo a una dimensione pari a zero e quindi eliminarlo:

 truncate -s 0  monthly.log && rm -f monthly.log

Come raccomandato da quanti, è necessario prima logrotarlo prima.


In cosa truncatedifferisce da >?
Kojiro,

hmm buona domanda. Il risultato è lo stesso, ma non ho risposta in che modo differiscano nell'attuazione.
Daniel t.

Il truncatepiù facile da usare con sudorispetto >. È anche più facile con find -exec.
kubanczyk,


3

Tronco / azzererei il file con l' : > /path/to/monthly.logoperazione. Quindi eventualmente riavviare il processo Apache e impostare la rotazione del registro per evitare che ciò accada in futuro ...

Questo viene spesso, però:

Vedi: Esiste un modo per eliminare file da 100 GB su Linux senza bloccare IO / caricare?

In unix, qual è il modo migliore per ridurre le dimensioni di un enorme file di registro su cui si sta scrivendo attivamente?

Server Linux esaurito


Non c'è bisogno di :. Puoi semplicemente fare> /path/to/monthly.log
kojiro il

So che è un noop, ma ha più senso da una prospettiva didattica.
ewwhite,

... ma poi un futuro istruttore deve correggere quel malinteso. Oh bene, immagino sia la sicurezza del lavoro.
Kojiro,

Non true > /path/to/monthly.logfarebbe la stessa cosa, ed è meno arcaico allora :?
Stefan Lasiewski,

Probabilmente vero ...
ewwhite il

3

Se non hai bisogno dei dati, troncali usando / dev / null:

cat /dev/null > monthly.log

Il server web continuerà a scrivere i dati nel file dopo il troncamento, evitando così la necessità di riavviare il server Web (diversamente rm monthly.log, che rimuove il file).

Dopo aver risolto la crisi immediata, prendere in considerazione la registrazione come suggerito da Quanta. Non vuoi che questo accada di nuovo. Si noti che i file di log di Apache sono già ruotati per impostazione predefinita su CentOS

Considera anche di inviare i log web tramite syslog (usando /usr/bin/logger, ad esempio). I log che vengono creati utilizzando syslog di solito hanno già impostato la logrotation.


5
Non puoi fare >logfilenulla per cat
user9517,

2

Se stai usando il filesystem ext3, considera di passare a ext4.

Ext3 può essere lento nell'eliminare file di grandi dimensioni perché memorizza la posizione di ogni singolo blocco 4k: un file 50GiB (50 * 1024 ^ 3 byte) occupa 13107200 blocchi, ognuno dei quali è registrato nella tabella di inode come un numero di blocco a 32 bit , per un totale di 50 MiB di dati contabili solo per tenere traccia di dove si trovano i contenuti del file sul disco. Tale elenco di blocchi di grandi dimensioni può essere sparso su molti blocchi indiretti , che devono essere aggiornati quando il file viene eliminato. Il disco che cerca di accedere a tutti quei blocchi indiretti è probabilmente ciò che sta causando il ritardo.

Ext4, d'altra parte, alloca i file in "estensioni" fino a 128 MiB. Quel file 50GiB può essere registrato nella tabella degli inode usando solo record di estensione di 400, anziché 13107200 numeri di blocco individuali, il che riduce drasticamente la quantità di I / O del disco necessaria durante l'eliminazione del file.

Notare che se si converte un filesystem ext3 esistente sul posto in ext4, i nuovi file verranno allocati usando extents, ma i file esistenti useranno comunque gli elenchi di blocchi. Puoi usare il chattr +ecomando per riallocare un file esistente usando extents; dal punto di vista delle prestazioni, è paragonabile a fare una copia del file e quindi a eliminare l'originale.


1

Questo si riduce a un problema di prestazioni del filesystem. C'è una risposta interessante a questa domanda SO, ma questo dipende piuttosto da quale filesystem stai usando. Ho usato XFS durante la creazione di un filesystem per memorizzare centinaia di file MPEG2 multi-gigabyte per MythTV perché all'epoca le prestazioni di eliminazione di XFS erano di gran lunga superiori a ext3. Le cose potrebbero essere cambiate considerevolmente negli anni successivi.

Mi piace però la risposta di @quanta. La suddivisione del file in parti più piccole porterà a una cancellazione più rapida.


1

Il problema deriva, suppongo, che stai eliminando il file dall'utente privilegiato che ha più priorità alle operazioni del disco rispetto all'utente del webserver apache. Indipendentemente dal modo in cui si sceglie di eliminare il file di registro (rm -f o troncato da>) è necessario ridurre al minimo le operazioni relative alla priorità del disco:

  ionice -c3 rm -f filename.log
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.