hemmiandra

Members
  • Posts

    29
  • Joined

  • Last visited

Everything posted by hemmiandra

  1. And as soon as I delete some files that are stored on Disk2, the disk displays normally, along with all other info. As soon as the disk fills completely up again, it shows the same crap nfo. This is funky..
  2. Nobody? This is causing all sorts of issues since my mapped drives are reporting rubbish numbers.
  3. I´m lost. I have absolutely no idea what's going on. Disk 2 is just giving með BS information all of a sudden. I tried rebooting the server, makes no difference. I´m running Dynamix webGui 2.0.2 and thought that it was just some PHP bug, but unMENU tells me the same as well as my mapped network drive. See screenshots: Ideas?
  4. I´m aware of the extra length the stream has to go. Having a standalone fileserver is just something of a good practice of mine. Keeping things seperate makes it easier to diagnose problems, revert the VM's back if serious problems occur, having a failover option when clustered etc. It's also a matter of hardware, my current unRAID machine is an older 775/C2Q/8GB RAM box, plenty for unRAID but not exactly much of a VM server. I've got about 50+ users accessing my content, most of them through Plex but some over FTP or VPN in rare occasions, so I need to keep my Plex setup on the 8 core Hyper-V machine. It probably adds to the equation that I´m an MCITP, so I´m much more comfortable troubleshooting things in the M$ enviroment than *nix based systems, and with that userbase I don't like to be at the mercy of google/forums I don't really have much faith in those consumer switches but.. unRAID is the only machine giving me those random spikes, every other machine in the house that's Gbit wired (and there are about 7 of them) all respond within the <1ms range. I completely forgot about the safe mode option! I'm going to try that early in the morning when there's little to no traffic, thanks for the suggestion.
  5. Sorry if I wasn't clear enough The unRAID fileserver doesn't run anything but a plugin or two for monitoring and alerts. I also forgot to mention that I´m running the Dynamix WebGUI, if that can have anything to do with this. The virtual servers run everything in VM's - Plex, AD, DNS, VPN, FTP, p2p software etc. I like the sound of the v6 lite version, I´ll probably wait for the release of it before upgrading. I just tried putting in a new NIC, just to see if it could possibly be a funky hardware issue but it remains the same.
  6. I've been looking into upgrading, just don't feel the need to just yet. I don't run anything else on the box but unRAID and that's not something that will change, even if unRAID can do virtual now. I like to keep my fileserver just doing that, serving files, and that's it. I will def. upgrade at some point but since the server is heavily used pretty much 24/7 it's not something I´m going to rush into. This issue is relatively new, so it's very unlikely that it's a version specific issue. I've exp. some slowness in the past when the mover is working, and oddly I find the whole system run a bit slower when drives begin to fill up, but there's nothing in the system log that gives any indication as to what could be causing this. What I´m pretty much asking is, what would be the next logical step to do?
  7. I've been getting complaints from many of my Plex users about stuttering, and I've been having the issue myself for quite some time. It's not just noticeable in Plex, when I´m browsing shares on the unRAID server I get random slowness and timeouts, and some servers even lose connection with the mapped network shares which causes all sorts of problems with various software. I've got 3 physical servers, unRAID being one of them, and multiple VM's on the other servers and I've been pinging from server to server and all servers respond in the >1ms range, as expected, all server connected to the same Gbit switch. However, this is a small example of the results from the unRAID server. The only hardware aspect I could change was the network cable and switch port, that changed nothing. The stuttering in Plex is in check with the highest spikes, or when the spikes last for 10s or longer and the buffer isn't enough. Reply from 192.168.1.30: bytes=32 time=1259ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1124ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1792ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1760ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1288ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1903ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1518ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1282ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1109ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1483ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1534ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1674ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1408ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1010ms TTL=64 Reply from 192.168.1.30: bytes=32 time=773ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time<1ms TTL=64 Reply from 192.168.1.30: bytes=32 time=998ms TTL=64 Reply from 192.168.1.30: bytes=32 time=1573ms TTL=64 This goes on and on, even when there's no traffic at all from the server. Goes to <1ms for a couple of seconds, then spikes. What in the world could be causing this? This is just about making my unRAID server unusable.
  8. No, nothing underneath that line. I´ll look into the oom adjust and see where it gets me, thx.
  9. This is the output: root 30242 0.0 0.0 2204 640 pts/0 S+ 22:41 0:00 grep emhttp I'm pretty much not running any plugins beside unMenu and some minor email notification scripts configured for alerts. My Hyper-V cluster handles everything else, the unRaid machine is just a fileserver. It's nothing special, C2Q LGA775 setup, but 8GB of DDR3 should be enough for a basic FS role? I'd be surprised if it were running out of mem.
  10. Been running unRAID 5.0.4 for a couple of months, and I've always had this wierd issue. 2-4 days after a restart the web interface becomes completely unavailable, but a reboot fixes it. Not something I want to be doing every couple of weeks since my fileserver is pretty much serving up files through Plex and FTP 24/7/365. I´m also running unMenu and that keeps on responding on :8080 just fine for weeks and months. I´m a bit lost - What's the first thing I should take a look at?
  11. I unplugged the disk to get it replaced under warranty (really need to have a hot spare) and the system is at it's usual speed. I find it very uncomfortable that the web Interface becomes unresponsive when a disk fails. Quite the flaw.
  12. Hi. Just wanted to get a confirmation on this before taking action. My parity drive is reporting a lot of errors and bad sectors, and failing self DST so time for a replacement. Is the precedure any different when replacing the parity drive vs. data drive? On a side note, my interface stops responding after a while, and I sometimes have to reboot at least 2-3 times before I can access it. There seems to be no other connection to this problem other then the failing parity drive, so I´m kind of lost there since it makes no sense. EDIT: Oh, and can I access the storage pool/shares while parity drive is missing, as with data drives?
  13. I noticed the same thing since installing dynamix. Not one of my disks spin down. I've checked when the fileserver is in minimal or no use at all late at night/really early in the morning and all the disks are spun up, including the parity drive. I have the spin down time set at 1hour, all the drives are connected through sata multipliers and all the drives are 3TB seagates, same model. Is there any way of monitoring spin down/up activity? SMART values perhaps?
  14. Aah, interesting. What kind of hardware are you using, for reference?
  15. garion, what exactly are you showing us? active, passive, disabled.. what?
  16. Can you download the system temp PLG again and re-install it (right-click and choose "save link as"). I have added in the PLG the download of the latest lm-sensors package for slackware 13.1 (version 3.3.4), maybe with the newer version more is detected. Give it a try! Just installed it, no luck. Haven't tried to reboot the server since first install since it's in use by so many offsite users, but I dont expect that will yield better results.
  17. This is all the information I get: root@isis:~# sensors coretemp-isa-0000 Adapter: ISA adapter Core 0: +44.0 C (high = +82.0 C, crit = +100.0 C) Core 1: +40.0 C (high = +82.0 C, crit = +100.0 C) Core 2: +34.0 C (high = +82.0 C, crit = +100.0 C) Core 3: +39.0 C (high = +82.0 C, crit = +100.0 C) But thanks for the jGrowl tip, will look into it.
  18. I´m not sure I understand the Halt function in the Activity Stream. When I stop a filestream that's going to a Plex Media Server, I´m not allowed to stream that file again. The server see's the file as unavailable. Is there a time restriction in play? Also just a thought, would it be possible for the HDD icons under disk health to display some sort of visual notification in case of smart failure?
  19. Got everything up and running including those plugins, except for the temps. sensors cmd gives me the right information so unraid is reading the sensors correctly, but dynamix isn't reading it for some reason. Not sure where to go from here. But, the stats and disk health are the main attraction here, and I love it! Thanks so much, greatly appreciated! Now, the only thing missing from my perfect setup is a pushover notification plugin
  20. Yeah, it was. Removed it and it worked, thanks. You should add this step into the installation guide Also, those plugins on git that are available, do I install them in /boot/plugins og /config/plugins?
  21. I´m having some troubles installing Dynamix. I've tried both c/p the plg to the /boot/plugins folder and restarting after downloading it with "save link as" - as well as installing with installplg command. After the restart I get the normal WebGUI. Tried clearing the cache, another browser, another machine even, same. Running 5.0.2, with Darkstat, unMENU, btsync, proftpd and control_panel-ikosa plugins. Should any of these interfere? Should the webGui-latest-plg be in the plugins folder? Is that the 'oem' webgui? After the install I do see a new folder in /config/plugins with /dynamix/dynamix.webGui.cfg. What am I missing?
  22. Blinking green lights just means that it's spun down - which sounds about right since you're not using it. You can use your NAS just fine during parity check, but both the check and transfers from/to the NAS meanwhile will be much slower, but you won't cause any damage.
  23. Very interesting indeed. Although I'll probably never run anything other then fileserver-services or plugins on my unRAID, I´m always up for performance increase. Will def. be keeping my eye on this thread. My linux skills are pretty pathetic so everything that's "user friendly" sounds good to me
  24. Hi all. I've been having this issue randomly since I setup the server a week ago. More often then not, when I stop the array the server becomes totally unresponsive. Can not access the WebGUI, can not access via telnet, and cannot ping the server. I often work on the server remotely and this is causing me some serious issues. Any ideas why this is happening? Running 5.0.2 - Can't access the system log since I´m not onsite, but I understand that's where I'll probably find my answer.