NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS 3220 Locking up after upgrading to 6.2
Hello
Ever since we upgraded to 6.2 our RN3220 will lock up sometime over night when our backups are running. Requiring us to power off and on the device every morning.
We were running 6.1.8 before upgrading with no issues. System will not let me rollback to 6.1.8 now.
Running RAIDar is detecting device and displaying version as Support:64764. which maybe related to the issue?
Any help into this issue would be great.
Thanks
Ever since we upgraded to 6.2 our RN3220 will lock up sometime over night when our backups are running. Requiring us to power off and on the device every morning.
We were running 6.1.8 before upgrading with no issues. System will not let me rollback to 6.1.8 now.
Running RAIDar is detecting device and displaying version as Support:64764. which maybe related to the issue?
Any help into this issue would be great.
Thanks
93 Replies
Replies have been turned off for this discussion
- Well after restoring data back to NAS and running backup over the weekend it still locked up during backup last night!!!!
Oh and just noticed after restarting it this morning it reset our network setting to DHCP. We have it static assigned an IP. - Well, a factory reset is a new install and uses the the default settings.
- Updated to beta 10 yesterday. No lock up so far on first night.
Backup only took an hour when before it took 3+ hours to complete. Thats a major improvement if it continues to complete that fast the rest of week and over the weekend. - Well NAS locked up last night.
Running 6.3.3 beta 10top - 01:35:16 up 2 days, 16:08, 1 user, load average: 7.98, 3.41, 2.21
Tasks: 214 total, 13 running, 201 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 50.3 sy, 0.0 ni, 49.2 id, 0.1 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 3937904 total, 3737564 used, 200340 free, 600 buffers
KiB Swap: 5237116 total, 28 used, 5237088 free, 1904880 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
665 root 20 0 0 0 0 R 99.8 0.0 68:53.94 kswapd0
3702 root 20 0 0 0 0 R 99.8 0.0 47:34.55 nfsd
3358 root 20 0 250m 5180 3132 S 0.3 0.1 10:28.70 smbd
3472 root 19 -1 1521m 42m 3788 R 0.3 1.1 3:37.40 readynasd
13658 root 20 0 28568 1504 976 R 0.3 0.0 2:01.73 top
1 root 20 0 47984 3960 996 S 0.0 0.1 0:01.79 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:05.63 kthreadd
3 root 20 0 0 0 0 R 0.0 0.0 1:42.39 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root rt 0 0 0 0 R 0.0 0.0 0:00.31 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 1:43.39 rcu_sched
10 root rt 0 0 0 0 R 0.0 0.0 0:00.88 watchdog/0
11 root rt 0 0 0 0 R 0.0 0.0 0:00.87 watchdog/1
12 root rt 0 0 0 0 R 0.0 0.0 0:00.29 migration/1
13 root 20 0 0 0 0 R 0.0 0.0 0:48.14 ksoftirqd/1
15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H - Was that top output the last moment that the NAS was accessible? Looks like the kernel is trying exceptionally hard to do memory reclaim. One thing you could try is:
# echo vm.swappiness = 0 > /etc/sysctl.d/99-swappiness.conf
# sysctl --system - Or better yet, try 6.3.3 Beta 11 first. This build disables memory compaction, which can sometimes not play nice with heavy NFS workloads.
- Yeah I have ssh window open with TOP running so we can see when NAS locks up.
It locked up again so will update to 6.3.3 beta 11 this morning. - Locked up still. Are backup starts at 1am
top - 01:41:15 up 17:54, 1 user, load average: 8.04, 3.43, 2.21
Tasks: 205 total, 12 running, 193 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 50.4 sy, 0.0 ni, 49.1 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 3937944 total, 3564032 used, 373912 free, 600 buffers
KiB Swap: 5237116 total, 0 used, 5237116 free, 1701644 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
668 root 20 0 0 0 0 R 100.1 0.0 3:15.57 kswapd0
3811 root 20 0 0 0 0 R 99.8 0.0 15:07.78 nfsd
1859 root 20 0 56184 2148 1824 S 0.3 0.1 0:01.50 systemd-journal
5223 root 20 0 28576 1496 932 R 0.3 0.0 0:57.79 top
1 root 20 0 47972 4016 1084 S 0.0 0.1 0:01.00 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.04 kthreadd
3 root 20 0 0 0 0 R 0.0 0.0 0:21.88 ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/0:0H
7 root rt 0 0 0 0 R 0.0 0.0 0:00.08 migration/0
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_bh
9 root 20 0 0 0 0 S 0.0 0.0 0:34.49 rcu_sched
10 root rt 0 0 0 0 R 0.0 0.0 0:00.25 watchdog/0
11 root rt 0 0 0 0 R 0.0 0.0 0:00.25 watchdog/1
12 root rt 0 0 0 0 R 0.0 0.0 0:00.07 migration/1
13 root 20 0 0 0 0 R 0.0 0.0 0:14.40 ksoftirqd/1
15 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/1:0H
16 root rt 0 0 0 0 S 0.0 0.0 0:00.25 watchdog/2
17 root rt 0 0 0 0 S 0.0 0.0 0:00.10 migration/2
18 root 20 0 0 0 0 S 0.0 0.0 0:38.64 ksoftirqd/2
20 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/2:0H
21 root rt 0 0 0 0 S 0.0 0.0 0:00.25 watchdog/3
22 root rt 0 0 0 0 S 0.0 0.0 0:00.14 migration/3
23 root 20 0 0 0 0 S 0.0 0.0 0:17.50 ksoftirqd/3
25 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 kworker/3:0H
26 root 0 -20 0 0 0 S 0.0 0.0 0:00.00 khelper
337 root 20 0 0 0 0 R 0.0 0.0 0:00.34 kworker/1:2 Skywalker wrote: Was that top output the last moment that the NAS was accessible? Looks like the kernel is trying exceptionally hard to do memory reclaim. One thing you could try is: # echo vm.swappiness = 0 > /etc/sysctl.d/99-swappiness.conf
# sysctl --system
I applied the above code today. Will see if that makes a difference.- Locked up again.
I got PM will send you copy of our scripts that run.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
