Re: iowait

[Davide Prina]

On 27/09/21 11:09, Piviul wrote:

...ora sto cercando di fare un rsync di una cartella remota con 2.7T di 
dati e le performance sono disastrose;


latenza


Che sia dovuto al fatto che il volume logico è in mirror?


può essere che anche questo influisca sull'aumento della latenza. Ma è 
software o hardware?


Sep 27 10:55:57 backup-server kernel: [10150.695843] INFO: task 
jbd2/dm-23-8:1568 blocked for more than 120 seconds.
Sep 27 10:55:57 backup-server kernel: [10150.695871] Tainted: 
G  I   5.10.0-8-amd64 #1 Debian 5.10.46-4
Sep 27 10:55:57 backup-server kernel: [10150.695892] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 27 10:55:57 backup-server kernel: [10150.695935] 
task:jbd2/dm-23-8    state:D stack:    0 pid: 1568 ppid: 2 
flags:0x4000

Sep 27 10:55:57 backup-server kernel: [10150.695939] Call Trace:
Sep 27 10:55:57 backup-server kernel: [10150.695950] 
__schedule+0x282/0x870
Sep 27 10:55:57 backup-server kernel: [10150.695955]  ? 
out_of_line_wait_on_bit_lock+0xb0/0xb0

Sep 27 10:55:57 backup-server kernel: [10150.695957] schedule+0x46/0xb0
Sep 27 10:55:57 backup-server kernel: [10150.695960] 
io_schedule+0x42/0x70

Sep 27 10:55:57 backup-server kernel: [10150.695962] bit_wait_io+0xd/0x50
Sep 27 10:55:57 backup-server kernel: [10150.695965] 
__wait_on_bit+0x2a/0x90
Sep 27 10:55:57 backup-server kernel: [10150.695968] 
out_of_line_wait_on_bit+0x92/0xb0
Sep 27 10:55:57 backup-server kernel: [10150.695973]  ? 
var_wake_function+0x20/0x20

[...]

cercando sembra che il problema possa essere dovuto al fatto che il 
sistema non riesca a scrivere su disco abbastanza velocemente tutte le 
pagine in memoria che sono state modificate...


prova a vedere cosa contengono questi due:
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_background_ratio

e prova a diminuirli, ad esempio dimezzarli con echo

# echo $VALORE > /proc/sys/vm/dirty_ratio

Come sempre le modifiche in sys sono temporanee fino al prossimo 
riavvio, per renderle persistenti devi inserirle nel file /etc/sysctl.conf


Quindi il tempo di latenza aumenta per questa operazione. In pratica 
stai superando la velocità massima supportata dal tuo disco in 
scrittura... rsync arriva a dover attendere che si liberi memoria per 
poter continuare a trasferire i dati.
Questo potrebbe essere dovuto anche al fatto che non è impostato 
correttamente il disco/raid/sistema (una volta potevi migliorare le 
prestazioni del disco giocando sui parametri e abilitandone altre, con i 
dischi moderni non so se sia ancora fattibile) o c'è qualche problema su 
un disco o sul raid



do_syscall_64+0x33/0x80
Sep 27 10:55:57 backup-server kernel: [10150.696387] 
entry_SYSCALL_64_after_hwframe+0x44/0xa9
Sep 27 10:55:57 backup-server kernel: [10150.696390] RIP: 
0033:0x7feeab1b0f33
Sep 27 10:55:57 backup-server kernel: [10150.696392] RSP: 
002b:7ffef85496d8 EFLAGS: 0246 ORIG_RAX: 0001
Sep 27 10:55:57 backup-server kernel: [10150.696395] RAX: 
ffda RBX: 5639ef415bc0 RCX: 7feeab1b0f33
Sep 27 10:55:57 backup-server kernel: [10150.696396] RDX: 
0004 RSI: 5639ef415bc0 RDI: 0003
Sep 27 10:55:57 backup-server kernel: [10150.696398] RBP: 
0003 R08: 8000 R09: 8000
Sep 27 10:55:57 backup-server kernel: [10150.696399] R10: 
0658aeb7 R11: 0246 R12: 8000
Sep 27 10:55:57 backup-server kernel: [10150.696401] R13: 
0004 R14: 5639f07883d0 R15: 7ffef85497c8


questi però non penso che centrino con gli altri messaggi di warning
Ma journalctl te li mostra dello stesso colore delle altre righe?

Secondo me hai due problemi e questo è il secondo.
O magari questo causa mini-freeze del sistema che causano l'altro problema.

Magari c'è qualche problema/bug sul firmware di qualche componente... o 
un bug in Linux... o un problema hardware


Ho anche visto che ti sei ricompilato Linux o hai ricompilato o usato 
moduli non ufficiali (non firmati), magari hai disabilitato qualcosa che 
ti serve o hai abilitato qualcosa che non è compatibile


ho trovato questo:
https://www.kernel.org/doc/html/v5.0/dev-tools/kasan.html
che però non mi sembra una cosa così banale da fare... e poi dopo che 
hai i risultato non mi sembra così capibile...


Ciao
Davide
--
Dizionari: http://linguistico.sourceforge.net/wiki
$
Perché microsoft continua a compiere azioni illegali?:
http://linguistico.sf.net/wiki/doku.php?id=traduzioni:ms_illegal
GNU/Linux User: 302090: http://counter.li.org
Non autorizzo la memorizzazione del mio indirizzo su outlook

Re: Risolto (era: Vlan, Debian, VPN, zoneminder...)

[Piviul]

Il 26/09/21 13:59, Giuliano Curti ha scritto:
Il sab 25 set 2021, 07:45 Giuliano Curti > ha scritto:


Il sab 25 set 2021, 07:03 Giancarlo Martini
mailto:giancarlo@gmail.com>> ha scritto:

.

Se esponi delle porte con un ip pubblico ti consiglio di usare
fail2ban e pw adatte. Le suddette porte saranno sicuramente
oggetto di tentativi di accesso.


ecco che si apre un nuovo capitolo di studio :-)  :-) :-)


Ho guardato la documentazione di fail2ban, sembrerebbe non 
complicatissimo e quasi tutto già fatto; questo almeno per la SSH, ma 
per Motion e le telecamere quale comportamento suggerite?


fail2ban, se non ricordo male, si basa sul fatto che ogni failed access 
sicuramente viene memorizzato in qualche log. Per creare un plugin 
fail2ban per un certo servizio (motion? motioneye? zoneminder?) mi 
sembra di ricordare che sia sufficiente dirgli quale file di log 
monitorare (dipende il servizio dove memorizza l'auth failed) e una 
regular expression per estrapolare il failed auth... comunque ricordo 
che era piuttosto semplice e ben documentato; prova a dare un'occhiata.


Piviul

Re: LV Status NOT available

[Piviul]

mi rispondo da solo: lvchange -ay /dev/backup-server-vg/proxmox-store



Piviul

Il 27/09/21 08:39, Piviul ha scritto:
Ciao a tutti, ieri ho visto che nella copia di una cospicua mole di 
dati dalla rete su un server con installate alcune partizioni lvm, la 
copia stava impiegando più del solito così senza interrompere le 
scritture ho riavviato il server. Al riavvio le partizioni lv (fra le 
altre cose erano tutte in mirror) su cui si stavano scrivendo i dati 
sono in uno stato NOT AVAILABLE. La situazione ad esempio di una delle 
partizioni in questione è questa:



# lvdisplay backup-server-vg/proxmox-store
  --- Logical volume ---
  LV Path    /dev/backup-server-vg/proxmox-store
  LV Name    proxmox-store
  VG Name    backup-server-vg
  LV UUID    iH8zkJ-vWLw-vThb-5uVE-dKuk-iF85-D9pg36
  LV Write Access    read/write
  LV Creation host, time backup-server, 2021-09-08 15:08:15 +0200
  LV Status  NOT available
  LV Size    1.00 TiB
  Current LE 262144
  Mirrored volumes   2
  Segments   1
  Allocation inherit
  Read ahead sectors auto


Qualcuno sa come renderle nuovamente available in modo da poter 
provare a fare un fsck e magari vedere se riesco a montarle?


Grazie

Piviul

iowait

[Piviul]

Ciao a tutti, ho creato un server fisico con 2 dischi meccanici da 14T 
(MG07ACA14TE) che dovrebbe servire per memorizzare grandi quantità di 
dati relativi a files che cambiano poco di frequente (1 volta al giorno 
circa, sono principalmente files di backup). Mi sembrava quindi che non 
dovessi preoccuparmi troppo delle performance... ma a quanto pare mi 
sbagliavo!


...ora sto cercando di fare un rsync di una cartella remota con 2.7T di 
dati e le performance sono disastrose; ad esempio iostat ora mi mostra 
una percentuale di iowait pari al 52,16%, atop lampeggia di rosso nei 2 
dischi con un busy time anche maggiore del 100%; periodicamente anche il 
volume logico su cui l'rsync scrive si colora di rosso mostrando un busy 
time spessissimo superiore al 90%...


Che sia dovuto al fatto che il volume logico è in mirror? Avete qualche 
consiglio su come poter accelerare la copia dei 2.7T di dati o su come 
testare la velocità di scrittura?


Mi sono accorto ora che finalmente anche il kernel si accorge che c'è 
qualcosa che non va. Queste sono le ultime righe nel kern.log:


Sep 27 10:55:57 backup-server kernel: [10150.695843] INFO: task 
jbd2/dm-23-8:1568 blocked for more than 120 seconds.
Sep 27 10:55:57 backup-server kernel: [10150.695871] Tainted: 
G  I   5.10.0-8-amd64 #1 Debian 5.10.46-4
Sep 27 10:55:57 backup-server kernel: [10150.695892] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 27 10:55:57 backup-server kernel: [10150.695935] 
task:jbd2/dm-23-8    state:D stack:    0 pid: 1568 ppid: 2 
flags:0x4000

Sep 27 10:55:57 backup-server kernel: [10150.695939] Call Trace:
Sep 27 10:55:57 backup-server kernel: [10150.695950] 
__schedule+0x282/0x870
Sep 27 10:55:57 backup-server kernel: [10150.695955]  ? 
out_of_line_wait_on_bit_lock+0xb0/0xb0

Sep 27 10:55:57 backup-server kernel: [10150.695957] schedule+0x46/0xb0
Sep 27 10:55:57 backup-server kernel: [10150.695960] io_schedule+0x42/0x70
Sep 27 10:55:57 backup-server kernel: [10150.695962] bit_wait_io+0xd/0x50
Sep 27 10:55:57 backup-server kernel: [10150.695965] 
__wait_on_bit+0x2a/0x90
Sep 27 10:55:57 backup-server kernel: [10150.695968] 
out_of_line_wait_on_bit+0x92/0xb0
Sep 27 10:55:57 backup-server kernel: [10150.695973]  ? 
var_wake_function+0x20/0x20
Sep 27 10:55:57 backup-server kernel: [10150.695984] 
jbd2_journal_commit_transaction+0x11a7/0x1ad0 [jbd2]
Sep 27 10:55:57 backup-server kernel: [10150.695996] 
kjournald2+0xab/0x270 [jbd2]
Sep 27 10:55:57 backup-server kernel: [10150.696000]  ? 
add_wait_queue_exclusive+0x70/0x70
Sep 27 10:55:57 backup-server kernel: [10150.696007]  ? 
load_superblock.part.0+0xb0/0xb0 [jbd2]

Sep 27 10:55:57 backup-server kernel: [10150.696011] kthread+0x11b/0x140
Sep 27 10:55:57 backup-server kernel: [10150.696013]  ? 
__kthread_bind_mask+0x60/0x60
Sep 27 10:55:57 backup-server kernel: [10150.696017] 
ret_from_fork+0x22/0x30
Sep 27 10:55:57 backup-server kernel: [10150.696024] INFO: task 
rsync:1880 blocked for more than 120 seconds.
Sep 27 10:55:57 backup-server kernel: [10150.696060] Tainted: 
G  I   5.10.0-8-amd64 #1 Debian 5.10.46-4
Sep 27 10:55:57 backup-server kernel: [10150.696100] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 27 10:55:57 backup-server kernel: [10150.696142] 
task:rsync   state:D stack:    0 pid: 1880 ppid:  1878 
flags:0x4000

Sep 27 10:55:57 backup-server kernel: [10150.696145] Call Trace:
Sep 27 10:55:57 backup-server kernel: [10150.696149] 
__schedule+0x282/0x870
Sep 27 10:55:57 backup-server kernel: [10150.696152]  ? 
sugov_update_single+0xca/0x1f0
Sep 27 10:55:57 backup-server kernel: [10150.696155]  ? 
out_of_line_wait_on_bit_lock+0xb0/0xb0

Sep 27 10:55:57 backup-server kernel: [10150.696157] schedule+0x46/0xb0
Sep 27 10:55:57 backup-server kernel: [10150.696160] io_schedule+0x42/0x70
Sep 27 10:55:57 backup-server kernel: [10150.696162] bit_wait_io+0xd/0x50
Sep 27 10:55:57 backup-server kernel: [10150.696164] 
__wait_on_bit+0x2a/0x90
Sep 27 10:55:57 backup-server kernel: [10150.696167] 
out_of_line_wait_on_bit+0x92/0xb0
Sep 27 10:55:57 backup-server kernel: [10150.696170]  ? 
var_wake_function+0x20/0x20
Sep 27 10:55:57 backup-server kernel: [10150.696177] 
do_get_write_access+0x276/0x3d0 [jbd2]
Sep 27 10:55:57 backup-server kernel: [10150.696185] 
jbd2_journal_get_write_access+0x63/0x80 [jbd2]
Sep 27 10:55:57 backup-server kernel: [10150.696212] 
__ext4_journal_get_write_access+0x77/0x120 [ext4]
Sep 27 10:55:57 backup-server kernel: [10150.696235] 
ext4_reserve_inode_write+0x7f/0xb0 [ext4]
Sep 27 10:55:57 backup-server kernel: [10150.696256] 
__ext4_mark_inode_dirty+0x57/0x210 [ext4]
Sep 27 10:55:57 backup-server kernel: [10150.696274]  ? 
__ext4_journal_start_sb+0xf3/0x110 [ext4]
Sep 27 10:55:57 backup-server kernel: [10150.696295] 
ext4_dirty_inode+0x5f/0x80 [ext4]
Sep 27 10:55:57 backup-server kernel: [10150.696299] 
__mark_inode_dirty+0x24f/0x340
Sep 27 10:55:57 

LV Status NOT available

[Piviul]

Ciao a tutti, ieri ho visto che nella copia di una cospicua mole di dati 
dalla rete su un server con installate alcune partizioni lvm, la copia 
stava impiegando più del solito così senza interrompere le scritture ho 
riavviato il server. Al riavvio le partizioni lv (fra le altre cose 
erano tutte in mirror) su cui si stavano scrivendo i dati sono in uno 
stato NOT AVAILABLE. La situazione ad esempio di una delle partizioni in 
questione è questa:



# lvdisplay backup-server-vg/proxmox-store
  --- Logical volume ---
  LV Path    /dev/backup-server-vg/proxmox-store
  LV Name    proxmox-store
  VG Name    backup-server-vg
  LV UUID    iH8zkJ-vWLw-vThb-5uVE-dKuk-iF85-D9pg36
  LV Write Access    read/write
  LV Creation host, time backup-server, 2021-09-08 15:08:15 +0200
  LV Status  NOT available
  LV Size    1.00 TiB
  Current LE 262144
  Mirrored volumes   2
  Segments   1
  Allocation inherit
  Read ahead sectors auto


Qualcuno sa come renderle nuovamente available in modo da poter provare 
a fare un fsck e magari vedere se riesco a montarle?


Grazie

Piviul