petebnas Posted March 15, 2015 Share Posted March 15, 2015 I've been doing all sorts of tinkering with my system lately, and everything seems to be going in a good direction except the GUI (6.0 beta 14b). I had a fresh reboot, guiw as fine...then I ran a preclear from a console session, and I couldn't get to the GUI the entire time. The preclear wrapped up, and the gui was still unavailable. The whole time, though, I could get into the unmenu interface just fine. I consoled back into the nas and did a 'shutdown -r -t 0 now' and it rebooted just fine, and the gui works fine again, except it considered it an unclean shutdown, so it wants to do another preclear. If I start the array, cancel the parity check, and run the same command, it'll work fine...but something along the line gets the GUI out of line...and perhaps more that I'm not aware of, and it seems like the reboot is the only way to revive it... Any tips on what I could provide or try to do to get around this? Pete Link to comment
petebnas Posted March 15, 2015 Author Share Posted March 15, 2015 Only 2gb at the moment.. upgrading to new hardware next week with 8gb on board to start. It's always been pretty good for me at 2gb, I realize when I'm doing heavy I/o that it might not be accessible until the backup job or MC job or whatever wraps up, but with these newer 6beta versions, especially recently, it seems to have gotten fairly bad. I'm pretty sure I could run a command to restart the services when I was on v5, at least I had some notes about what to do, and that would usually fix it for me 9 times out of 10, but I haven't been able to track those notes down. Too many other parts changing in the meantime here, but wanted to pose the question to see what might be tied to this issue. Thinking I may be hitting a ram limit? Link to comment
SSD Posted March 15, 2015 Share Posted March 15, 2015 Change Settings -> Display Settings -> Page Update Frequency to "Disabled". Save the setting change. Reboot, and see if it continues. I had system instability allowing the GUI to continuously ping my drives for long periods of time. Since disabling that setting, it has been rock solid. When disabled, you have to manually refresh the GUI to see updates. Note that the constant pinging of the drives slows down the array. It also subjects the drives to SMART queries at a higher rate than they would have ever seen before. I have no idea if this could have some negative affect. But even if the SMART queries are harmless (which they probably are), and even if the instability is corrected, with the known slowdown I have no plans to re-enable. I am happy to refresh my GUI manually when I need to (just an F5 away!). Link to comment
petebnas Posted March 16, 2015 Author Share Posted March 16, 2015 Thanks for the tip - I'll give it a shot. Mine was definitely not set for 'disabled', yet I don't really get any updates until I hit refresh anyway...at least not ones I pick up on (I'm always hitting refresh to get the latest update after a MC data move, for example...not expecting the data to be dynamically updated correctly. Plus, half the time I go to refresh the screen doesn't come up at all, so it can't be 'that dynamic' if the system is unable to even display the page for hours on end...kind of odd. Good stuff, I'll see what happens! Pete Link to comment
itimpi Posted March 16, 2015 Share Posted March 16, 2015 Thanks for the tip - I'll give it a shot. Mine was definitely not set for 'disabled', yet I don't really get any updates until I hit refresh anyway...at least not ones I pick up on (I'm always hitting refresh to get the latest update after a MC data move, for example...not expecting the data to be dynamically updated correctly. Plus, half the time I go to refresh the screen doesn't come up at all, so it can't be 'that dynamic' if the system is unable to even display the page for hours on end...kind of odd. I think there are two inter-related issues here - the frequency with which the system 'thinks' the data should be updated, and the frequency with which the browser requests updates. I get different behaviour in this area according to the browser I use. With Chrome I have to hit the manual refresh, even though I can see it counting down to when it SHOULD refresh (and does not). Link to comment
bonienl Posted March 16, 2015 Share Posted March 16, 2015 In v6 the behavior of emhttp was changed to *not* invoke 'smartctl' each time a HTTP request was received, so enabling or disabling the page refresh should not have impact on disk performance afaik. The side effect of the new v6 behavior is that real-time updates do not happen for disk related information, all other info is updated according to the setting of the refresh timer, in the upcoming version this is 'somehow' corrected in the sense that disk info updates are done every minute in the background (still without invoking smartctl), while the webGUI shows the updated information as soon as its refresh timer expires. Link to comment
daan_SVK Posted March 21, 2015 Share Posted March 21, 2015 I'm having similar issues with the GUI flakiness, the array in general appears to be working so I'm assuming it is just the GUI itself that is unresponsive. The browser appears to be trying to retrieve data as the refresh wheel keeps spinning on my Tower Chrome Tab. I've come across multiple posts that suggested a lack of RAM might be causing emhttp being terminated, would someone be able to indeed confirm that based on the below, since it doenst tell me anything root@Tower:~# ps aux | grep emhttp root 1385 1.3 0.0 89076 3576 ? Rl Mar16 77:15 /usr/local/sbin/emhttp root 17745 0.0 0.0 5104 1720 pts/0 S+ 19:45 0:00 grep emhttp root@Tower:~# free -m total used free shared buffers cached Mem: 3560 3339 220 0 169 2805 -/+ buffers/cache: 364 3196 Swap: 0 0 0 if restarting the whole server is the preferred way to get the GUI back, what's the best way to go about a clean shutdown from the console. Link to comment
stchas Posted March 22, 2015 Share Posted March 22, 2015 I'm having similar issues with the GUI flakiness, the array in general appears to be working so I'm assuming it is just the GUI itself that is unresponsive. The browser appears to be trying to retrieve data as the refresh wheel keeps spinning on my Tower Chrome Tab. I'm seeing similar behavior with Firefox browser while doing a preclear of a 3TB drive on my Test Server in a PuTTY session. Array is stopped while I'm running the preclear. In v6 the behavior of emhttp was changed to *not* invoke 'smartctl' each time a HTTP request was received, so enabling or disabling the page refresh should not have impact on disk performance afaik. The side effect of the new v6 behavior is that real-time updates do not happen for disk related information, all other info is updated according to the setting of the refresh timer, in the upcoming version this is 'somehow' corrected in the sense that disk info updates are done every minute in the background (still without invoking smartctl), while the webGUI shows the updated information as soon as its refresh timer expires. This snippet of my syslog confirms the disk info scans. No calls to smartctl. These are occurring approximately every 80 seconds. Mar 22 06:58:00 Tower2 logger: Scanning for Btrfs filesystems Mar 22 06:58:00 Tower2 emhttp: Device inventory: Mar 22 06:58:00 Tower2 emhttp: ST3000VN000-1HJ166_xxxxxxxx (sda) 2930266584 Mar 22 06:58:00 Tower2 emhttp: ST3400632A_xxxxxxxx (sdb) 390711384 Mar 22 06:58:00 Tower2 emhttp: Maxtor_6L100P0_xxxxxxxx (sdc) 97906536 Mar 22 06:58:00 Tower2 emhttp: shcmd (7113): modprobe md-mod super=/boot/config/super.dat slots=4 |& logger Mar 22 06:58:00 Tower2 kernel: md: unRAID driver 2.4.0 installed Mar 22 06:58:00 Tower2 emhttp: import 4 cache device: sdc Mar 22 06:58:00 Tower2 emhttp: import flash device: sdd Mar 22 06:58:00 Tower2 kernel: mdcmd (1): import 0 0,0 Mar 22 06:58:00 Tower2 kernel: md: disk0 removed Mar 22 06:58:00 Tower2 kernel: mdcmd (2): import 1 0,0 Mar 22 06:58:00 Tower2 kernel: md: disk1 missing Mar 22 06:58:00 Tower2 kernel: mdcmd (3): import 2 0,0 Mar 22 06:58:00 Tower2 kernel: mdcmd (4): import 3 0,0 Mar 22 06:58:00 Tower2 emhttp: shcmd (7115): rmmod md-mod |& logger Mar 22 06:58:00 Tower2 kernel: md: unRAID driver removed Mar 22 06:58:00 Tower2 emhttp: Pro key detected, GUID: xxxx-xxxx-xxxx-xxxxxxxxxxxx FILE: /boot/config/Pro-xxxx-xxxx-xxxx-xxxxxxxxxxxx.key Mar 22 06:58:00 Tower2 emhttp: array slots: 4 Mar 22 06:58:00 Tower2 emhttp: cache slots: 1 Mar 22 06:58:00 Tower2 emhttp: shcmd (7116): udevadm settle Mar 22 06:58:00 Tower2 emhttp: shcmd (7117): /sbin/btrfs device scan |& logger Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.