Re: {* 05.00 *}Re: Desperate with 870 QVO and ZFS

Hi Eugene!!! 

Thank you so much really again mate  :) :) :) 

About your recommendations... Eugene, if some of them wouldn't be
working as expected, could we revert some or all of them or perhaps some
of your recommendations below need to be definitive?. 

I do answer below in green bold for better distinction :) :) 

El 2022-04-06 18:14, Eugene Grosbein escribió:

> ATENCION
> ATENCION
> ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No pinche en los enlaces ni abra los adjuntos a no ser que reconozca el remitente y sepa que el contenido es seguro.
> 
> 06.04.2022 22:30, egoitz@ramattack.net пишет: 
> 
>> One perhaps important note!!
>> 
>> When this happens... almost all processes appear in top in the following state:
>> 
>> txg state or
>> 
>> txg->
>> 
>> bio....
>> 
>> perhaps should the the vfs.zfs.dirty_data_max, vfs.zfs.txg.timeout, vfs.zfs.vdev.async_write_active_max_dirty_percent be increased, decreased.... I'm afraid of doing some chage ana finally ending up with an inestable server.... I'm not an expert in handling these values....
>> 
>> Any recommendation?.
> 
> 1) Make sure the pool has enough free space because ZFS can became crawling slow otherwise. 
> 
> THIS IS JUST AN EXAMPLE... BUT YOU CAN SEE ALL SIMILARLY.... 
> 
> ZPOOL LIST
> NAME             SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
> ZROOT             448G  2.27G   446G        -         -     1%     0%  1.00X  ONLINE  -
> MAIL_DATASET  58.2T  19.4T  38.8T        -         -    32%    33%  1.00X  ONLINE  -
> 
> 2) Increase recordsize upto 1MB for file systems located in the pool
> so ZFS is allowed to use bigger request sizes for read/write operations 
> 
> WE HAVE THE DEFAULT... SO 128K...
> 
> 3) If you use compression, look if achieved compressratio worth it and
> if not (<1.4 f.e.) then better disable compression to avoid its overhead; 
> 
> WE DON'T USE COMPRESSION AS IT'S NOT SET BY DEFAULT. SOME PEOPLE SAY YOU SHOULD HAVE IT ENABLED.... BUT.... JUST FOR AVOID HAVING SOME DATA COMPRESSED SOME OTHER NOT (IN CASE YOU ENABLE AND LATER DISABLE) AND FINALLY FOR AVOID ACCESSING TO INFORMATION WITH DIFFERENT CPU COSTS OF HANDLING... WE HAVE NOT TOUCHED COMPRESSION.... 
> 
> WE SHOULD SAY WE HAVE LOTS OF CPU... 
> 
> 4) try "zfs set redundant_metadata=most" to decrease amount of small writes to the file systems; 
> 
> OK.... 
> 
> 5) If you have good power supply and stable (non-crashing) OS, try increasing
> sysctl vfs.zfs.txg.timeout from defaule 5sec, but do not be extreme (f.e. upto 10sec).
> Maybe it will increase amount of long writes and decrease amount of short writes, that is good.
> 
> WELL I HAVE SYNC IN DISABLED IN THE DATASETS... DO YOU STILL THINK IT'S GOOD TO CHANGE IT?. JUST A QUESTION OF PERSON WANTING TO LEARN :) . 
> 
> WHAT ABOUT THE VFS.ZFS.DIRTY_DATA_MAX AND THE VFS.ZFS.DIRTY_DATA_MAX_MAX, WOULD YOU INCREASE THEM FROM 4GB IT'S SET NOW?. 
> 
> THANKS A LOT EUGENE!!!! 
> CHEERS!!