From nobody Thu Apr 7 08:49:15 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 388251AA426B; Thu, 7 Apr 2022 08:49:21 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from cu01208b.smtpx.saremail.com (cu01208b.smtpx.saremail.com [195.16.151.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4KYw6R6nMZz3k6B; Thu, 7 Apr 2022 08:49:19 +0000 (UTC) (envelope-from egoitz@ramattack.net) Received: from www.saremail.com (unknown [194.30.0.183]) by sieve-smtp-backend01.sarenet.es (Postfix) with ESMTPA id DADEA60C641; Thu, 7 Apr 2022 10:49:15 +0200 (CEST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_85ed0b4a49488ec1a940cb1f7fed0376" Date: Thu, 07 Apr 2022 10:49:15 +0200 From: egoitz@ramattack.net To: Eugene Grosbein Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, Freebsd performance Subject: Re: {* 05.00 *}Re: Re: Desperate with 870 QVO and ZFS In-Reply-To: References: <4e98275152e23141eae40dbe7ba5571f@ramattack.net> <665236B1-8F61-4B0E-BD9B-7B501B8BD617@ultra-secure.de> <0ef282aee34b441f1991334e2edbcaec@ramattack.net> <28e11d7ec0ac5dbea45f9f271fc28f06@ramattack.net> <7aa95cb4bf1fd38b3fce93bc26826042@ramattack.net> Message-ID: <55000f00fb64510e8ef6b8ad858d8855@ramattack.net> X-Sender: egoitz@ramattack.net User-Agent: Saremail webmail X-Rspamd-Queue-Id: 4KYw6R6nMZz3k6B X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=reject) header.from=ramattack.net; spf=pass (mx1.freebsd.org: domain of egoitz@ramattack.net designates 195.16.151.183 as permitted sender) smtp.mailfrom=egoitz@ramattack.net X-Spamd-Result: default: False [-3.79 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; XM_UA_NO_VERSION(0.01)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.16.151.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[ramattack.net,reject]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-fs,freebsd-hackers,freebsd-performance]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3262, ipnet:195.16.128.0/19, country:ES]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_85ed0b4a49488ec1a940cb1f7fed0376 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Good morning Eugene!! Thank you so much for your help mate :) :) really :) :) Ok I take good notes of all you have replied me below :) :) Very very thankful for your help really :) Cheers, El 2022-04-06 20:10, 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 23:51, egoitz@ramattack.net wrote: > >> About your recommendations... Eugene, if some of them wouldn't be working as expected, >> could we revert some or all of them > > Yes, it all can be reverted. > Just write down original sysctl values if you are going to change it. > >> 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 -* > > It's all right. > >> 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...* > > It will not hurt increasing it upto 1MB. > >> 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? > > Yes, try it. Disabling sync makes sense if you have lots of fsync() operations > but other small writes are not affected unless you raise vfs.zfs.txg.timeout > >> *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?.* > > Never tried that and cannot tell. --=_85ed0b4a49488ec1a940cb1f7fed0376 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Good morning Eugene!!


Thank you so much for your help mate :) :) really :) :)


Ok I take good notes of all you have replied me below :) :)


Very very thankful for your help really :)


Cheers,

 


El 2022-04-06 20:10, Eugene Grosbein escribió:

= ATENCION
ATENCION
ATENCION!!! Este correo se ha enviado desde f= uera 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 23:51, egoitz@ramat= tack.net wrote:

About your recommendations... Eugene, if some of them = wouldn't be working as expected,
could we revert some or all of them<= /blockquote>
Yes, it all can be reverted.
Just write down original sysctl v= alues if you are going to change it.

1) Make sure the pool has enough free space because ZF= S can became crawling slow otherwise.
 
*This is just an e= xample... but you can see all similarly....*
 
*zpool list= *
*NAME           &= nbsp; SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ &= nbsp; FRAG    CAP  DEDUP  HEALTH  ALTROO= T*
*zroot           = ;  448G  2.27G   446G     &nbs= p;  -         -  &nb= sp;  1%     0%  1.00x  ONLINE  = ;-*
*mail_dataset  58.2T  19.4T  38.8T   &nb= sp;    -        &nbs= p;-    32%    33%  1.00x  ONLINE &n= bsp;-*

It's all right.

2) Increase recordsize upto 1MB for file systems locat= ed in the pool
so ZFS is allowed to use bigger request sizes for read= /write operations
 
*We have the default... so 128K...*
It will not hurt increasing it upto 1MB.

5) If you have good power supply and stable (non-crash= ing) OS, try increasing
sysctl vfs.zfs.txg.timeout from defaule 5sec,= but do not be extreme (f.e. upto 10sec).
Maybe it will increase amou= nt 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?

Yes, try it. Disabling sync makes sense if you have lots of fsync() = operations
but other small writes are not affected unless you raise v= fs.zfs.txg.timeout

*What about the vfs.zfs.dirty_data_max and the vfs.zfs= =2Edirty_data_max_max, would you increase them from 4GB it's set now?.*
Never tried that and cannot tell.
--=_85ed0b4a49488ec1a940cb1f7fed0376--