Date: Fri, 1 Apr 2022 15:06:40 +0200 From: Christoph Brinkhaus <c.brinkhaus@t-online.de> To: Budi Janto <budijanto@studiokaraoke.co.id> Cc: William Dudley <wfdudley@gmail.com>, freebsd-questions@freebsd.org Subject: Re: Fatal trap 12 Message-ID: <Ykb44NoBHFys5o7%2B@celsius> In-Reply-To: <0958bfdb-ebad-c860-8138-6e7010293c43@studiokaraoke.co.id> References: <2f1cf9d8-b9b0-4ec1-50fc-ebd4f469a82b@studiokaraoke.co.id> <CAFsnNZLMxLT9mL4Y_9QvYqsLhitn=5ZzaOEJ6SUJO5Oo4BgE7g@mail.gmail.com> <0958bfdb-ebad-c860-8138-6e7010293c43@studiokaraoke.co.id>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Fri, Apr 01, 2022 at 04:49:52AM +0700 schrieb Budi Janto: Hello Budi! > On 4/1/22 04:31, William Dudley wrote: > > bad RAM? > > > > Bill Dudley > > I don't know exactly what happened, but I forgot to tell that ZFS > Scrubbing was running when this issue came up. > > # sysctl -a | grep 'hw.*mem' > hw.physmem: 17035481088 > hw.usermem: 14230319104 > hw.realmem: 17179869184 > hw.pci.host_mem_start: 2147483648 > hw.cbb.start_memory: 2281701376 > > # top -b > last pid: 2621; load averages: 0.81, 0.73, 0.54 up 0+00:54:00 > 04:44:40 > 28 processes: 1 running, 27 sleeping > CPU 0: 0.0% user, 0.0% nice, 6.2% system, 6.5% interrupt, 87.2% idle > CPU 1: 0.0% user, 0.0% nice, 6.7% system, 0.0% interrupt, 93.2% idle > CPU 2: 0.0% user, 0.0% nice, 6.0% system, 0.2% interrupt, 93.8% idle > CPU 3: 0.0% user, 0.0% nice, 6.0% system, 0.2% interrupt, 93.8% idle > Mem: 159M Active, 2714M Inact, 2673M Wired, 345M Buf, 10G Free > ARC: 795M Total, 717M MFU, 66M MRU, 10M Header, 1856K Other > 755M Compressed, 5172M Uncompressed, 6.85:1 Ratio > Swap: 3979M Total, 3979M Free > It might help to limit the arc. I have in /boot/loader.conf lines as below: # grep arc /boot/loader.conf vfs.zfs.compressed_arc_enabled="0" vfs.zfs.arc_max="500M" I am not sure why I have disabled compressed arc, too. It is likely due to some advise. > PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU > COMMAND > 968 root 1 20 0 32M 12M select 0 0:03 0.00% > snmpd > 2227 mysql 37 20 0 2737M 279M select 3 0:02 0.00% > mysqld > 944 nobody 1 20 0 18M 7272K select 2 0:00 0.00% > openvpn > 938 ntpd 1 20 0 21M 5028K select 3 0:00 0.00% ntpd > 360 _pflogd 1 20 0 13M 2996K bpf 3 0:00 0.00% > pflogd > 2372 wilson 1 20 0 21M 9324K select 1 0:00 0.00% sshd > 999 mysql 1 52 0 13M 3020K wait 0 0:00 0.00% sh > 2378 root 1 20 0 16M 4840K pause 3 0:00 0.00% csh > 856 root 1 20 0 13M 2624K select 1 0:00 0.00% > syslogd > 1118 root 1 23 0 13M 2644K nanslp 3 0:00 0.00% cron > 2369 root 1 20 0 21M 9284K select 2 0:00 0.00% sshd > 2373 wilson 1 21 0 14M 4192K pause 2 0:00 0.00% csh > 2377 wilson 1 20 0 13M 3168K wait 2 0:00 0.00% su > 660 root 1 20 0 11M 1412K select 3 0:00 0.00% devd > 664 root 1 20 0 19M 5840K select 1 0:00 0.00% zfsd > 1187 root 1 52 0 13M 2268K ttyin 1 0:00 0.00% > getty > 1191 root 1 52 0 13M 2268K ttyin 3 0:00 0.00% > getty > 1184 root 1 52 0 13M 2268K ttyin 3 0:00 0.00% > getty > > # zpool status -v > pool: pool > state: ONLINE > scan: scrub in progress since Fri Apr 1 01:00:00 2022 > 4.75T scanned at 0B/s, 3.96T issued at 0B/s, 4.91T total > 0B repaired, 80.60% done, no estimated completion time > config: > > NAME STATE READ WRITE CKSUM > pool ONLINE 0 0 0 > diskid/DISK-WD-WMC1T1587601p1 ONLINE 0 0 0 > diskid/DISK-WD-WCC1T1170612p1 ONLINE 0 0 0 > diskid/DISK-Z1F5T8W1p1 ONLINE 0 0 0 > > errors: No known data errors > > Thank You. BTW: There has been a thread about memory issues in the FreeBSD forum where ZFS and mysql has been involved. As far as I remember it has been stated that mysql can be a memory hog, too. Limiting ARC has helped but I do not remember if there has been some additional tuning on mysql required, too. Kind regards, Christoph
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Ykb44NoBHFys5o7%2B>