January 15, 201313 yr I lose access to the web console...it never comes back. When this happens can you telnet into the box and do "netstat -nope" Do you see emhttp there with a TCP session in CLOSE_WAIT ? It just did it while running a parity check! The web interface was unresponsive. root@nas:~# netstat -nope Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name Timer tcp 0 264 10.1.1.20:22 10.1.1.9:52952 ESTABLISHED 0 292526 17288/0 on (0.38/0/0) Active UNIX domain sockets (w/o servers) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ] DGRAM 2796 857/udevd @/org/kernel/udev/udevd unix 3 [ ] DGRAM 2801 857/udevd unix 3 [ ] DGRAM 2800 857/udevd And it does appear that the parity check is still running. It should finish up in the next few hours.
January 15, 201313 yr I wish that I could find another decent IPMI mb. I like my Tyan S5512GM2NR it is a full ATX MB that supports the same CPUs that the X9SCM-F does and has IPMI - Web interface only. I've gotten bad MBs from both Tyan and SuperMicro so not sure I prefer one over the other. I switched because I wanted a full ATX MB and didn't like SuperMicro's full atx board - only wanted a single PCI or less port and Tyan won that by having just one - SuperMicro's equivalent MB had 3.
January 15, 201313 yr I would like to recommend that all of those with slow writes (who haven't already reported it) to post with their motherboard, amount of RAM, and number of hard disks, or put this info in their sigs as many here have already done. Why the amount of RAM? I can't help noticing that many of them appear to have huge amounts, 16GB or more, and illogical as it seems, it would not be the first time in this industry that adding large amounts of RAM actually broke systems or caused them to run somewhat slower. You may want to try removing RAM, back to 2GB or 4GB, and retesting... If nothing else, we will at least have the list of motherboards affected by this.
January 15, 201313 yr I would like to recommend that all of those with slow writes (who haven't already reported it) to post with their motherboard, amount of RAM, and number of hard disks, or put this info in their sigs as many here have already done. I think that it would be worth recording which processor, too. The X9 series of boards can use Xeon E3-1200 and 1200 V2 CPUs. Also, 2nd/3rd generation Core i and Pentium or Celeron.
January 15, 201313 yr unRAID 5.0-RC10 Norco RPC-4224 CH, X9SCM-F-O MB, E3-1230 Xeon CPU, Kingston 8GB 240-Pin DDR3 SDRAM ECC Unbuffered DDR3 1333 RAM, CORSAIR HX Series HX850 850W PS, SUPERMICRO AOC-SASLP-MV8 RC x3 -WD 4TB 7200 Black x1 -Hitachi 4TB 7200 x8
January 15, 201313 yr I would like to recommend that all of those with slow writes (who haven't already reported it) to post with their motherboard, amount of RAM, and number of hard disks, or put this info in their sigs as many here have already done. Why the amount of RAM? I can't help noticing that many of them appear to have huge amounts, 16GB or more, and illogical as it seems, it would not be the first time in this industry that adding large amounts of RAM actually broke systems or caused them to run somewhat slower. You may want to try removing RAM, back to 2GB or 4GB, and retesting... If nothing else, we will at least have the list of motherboards affected by this. 16GB was just really cheap.. lol that was the only reason for me. I switched back to 4gb and seems to be okay now. I will update my sig later with the detail
January 15, 201313 yr My config is a X9SCM-F with 16Gb RAM - linked to from my sig below - no issues at all here, though running in a VM with only 2Gb allocated to unRaid. Writes are happening at ~40MB/s +/- a few MB/s as they should.
January 15, 201313 yr I would like to recommend that all of those with slow writes (who haven't already reported it) to post with their motherboard, amount of RAM, and number of hard disks, or put this info in their sigs as many here have already done. Why the amount of RAM? I can't help noticing that many of them appear to have huge amounts, 16GB or more, and illogical as it seems, it would not be the first time in this industry that adding large amounts of RAM actually broke systems or caused them to run somewhat slower. You may want to try removing RAM, back to 2GB or 4GB, and retesting... If nothing else, we will at least have the list of motherboards affected by this. I believe the reason most of the people are running large amounts of RAM are because they are running unraid in a VM in conjunction with a Xeon processor. That RAM might not all be dedicated to that VM though. So it would be interesting to see the percentage of people that have this issue that are also running a Xeon processor. Those that are are far more likely to be running unraid in a VM. Does changing the RAM allotment to that VM affect the issue? Could this be related to running unraid in a VM and/or be related to VMWare's ESXi drivers and how they interact with a 32-bit Linux environment? If possible could these people boot directly to unraid and see if this issue still occurs? Haven't read the thread so this may have already been discussed but just some thoughts. I run the X9SCM with a Core i3 and 8GB of RAM, obviously in a non VM environment, and have had zero issues with any speeds.
January 15, 201313 yr I'm having this issue and look at my rig.. lol I'm going to guess that it's due to large amount of ram allocated to unRAID. I switched back to 4GB from 16GB and having no problem with writing.. without setting highmem_is_dirtyable To replicate this issue, set highmem_is_dirtyable back to 0 if you have it set at 1. "sysctl vm.highmem_is_dirtyable=0" and copy a huge file (5 - 10GB) through the network. Copying files less than 5GB may seem to work correctly.. Well that's what happened to me at least.
January 15, 201313 yr Does the "sysctl vm.highmem_is_dirtyable=1" command totally disable that problematic patch that seems to cause the problem? Or does it just tweak the patch? In the latter case maybe it would be worth a try totally reverting that problematic patch?
January 15, 201313 yr I think I have a 4GB DIMM I can pull out of another server. Ill see how it goes.
January 15, 201313 yr See my sig. No VM Will order 4 gig tonight and report back. I just ordered a Samsung DDR3-1600 4Gig piece, it is a module that is adviced by Supermicro: MEM-DR340L-SL01-EU16 http://tweakers.net/pricewatch/323590/supermicro-mem-dr340l-sl01-eu16/specificaties/ I still concider this a linux (kernel, not so much unraid) bug however... In the earlier version the issue is not present.. But if I can solve this with throwing 50 euro at it I'm glad to have got rid of it.. And as soon as the 16bit version of unraid arrives I can reuse the 16gigs again and I'll use the 4gigs for an htpc :-)
January 15, 201313 yr No issue here with the same SM X9SC-F-O. Likely the 1.0 version though. I have a i3 2100 and only 4GB of RAM. Solid as a rock for me with 2 - IBM m1015 and 1 - AOC-SASLP-MV8 on Antec 620C inside a Norco 4224 i3 X9SCM-F-O, feeding a bunch of 2 and 3tb drives
January 15, 201313 yr Ok here are my findings: First image within the green lines is a 42GB transfer to the server. Second image shows, to the left of the green line, when the sysctl vm.highmem_is_dirtyable=0 setting is applied, average data rate of 35-40MB/sec. To the right of the image is when sysctl vm.highmem_is_dirtyable=1, high speed bursts of max network (108.2MB/sec), then a pause, then another burst, then up/down constant. Resulting in an average of about 55-60MB/sec. The disk at 100GB full can do >80MB/sec, so what on earth is slowing it down?!?!
January 15, 201313 yr With the paramter at 1 I am happy to get 20 MB/sec ... Without it I get down to 500 KB/sec ..
January 15, 201313 yr My config is a X9SCM-F with 16Gb RAM - linked to from my sig below - no issues at all here, though running in a VM with only 2Gb allocated to unRaid. Writes are happening at ~40MB/s +/- a few MB/s as they should. This is nice... we have the same motherboard and the same amount of memory... You get ok speeds I get bug nothing... Difference is you are using only 2gig in a vm setup.. There have been earlier signals of less memory helping out, my switching back to 8gig (one bank) did nothing performance wise... I will now try to go back to 4gig.. See what that does.. I should be able to report back somewhere this weekend ..
January 15, 201313 yr You can also try a boot time parameter to limit ram. I've done this on more then one occasion to simulate a low ram system when testing buffering. mem=MEMEORY_SIZE http://www.cyberciti.biz/tips/10-boot-time-parameters-you-should-know-about-the-linux-kernel.html
January 15, 201313 yr You can also try a boot time parameter to limit ram. I've done this on more then one occasion to simulate a low ram system when testing buffering. mem=MEMEORY_SIZE http://www.cyberciti.biz/tips/10-boot-time-parameters-you-should-know-about-the-linux-kernel.html Now thats a good thing to know... Let me check if I understand how to set this..
January 15, 201313 yr Had a quick read of the link but I cannot find how to enter such paramter, any chance on a quick howto ?
January 15, 201313 yr My config is a X9SCM-F with 16Gb RAM - linked to from my sig below - no issues at all here, though running in a VM with only 2Gb allocated to unRaid. Writes are happening at ~40MB/s +/- a few MB/s as they should. This is nice... we have the same motherboard and the same amount of memory... You get ok speeds I get bug nothing... Difference is you are using only 2gig in a vm setup.. There have been earlier signals of less memory helping out, my switching back to 8gig (one bank) did nothing performance wise... I will now try to go back to 4gig.. See what that does.. I should be able to report back somewhere this weekend .. From what I can see, BetaQuasi and you have VERY different configs! Beta is running unRAID on top is ESXi.
January 15, 201313 yr My config is a X9SCM-F with 16Gb RAM - linked to from my sig below - no issues at all here, though running in a VM with only 2Gb allocated to unRaid. Writes are happening at ~40MB/s +/- a few MB/s as they should. This is nice... we have the same motherboard and the same amount of memory... You get ok speeds I get bug nothing... Difference is you are using only 2gig in a vm setup.. There have been earlier signals of less memory helping out, my switching back to 8gig (one bank) did nothing performance wise... I will now try to go back to 4gig.. See what that does.. I should be able to report back somewhere this weekend .. From what I can see, BetaQuasi and you have VERY different configs! Beta is running unRAID on top is ESXi. That is exactly what I wrote... We have same underlying hardware but BetaQuasi has a 2gig VM instead of bare metal.
January 15, 201313 yr You can also try a boot time parameter to limit ram. I've done this on more then one occasion to simulate a low ram system when testing buffering. mem=MEMEORY_SIZE http://www.cyberciti.biz/tips/10-boot-time-parameters-you-should-know-about-the-linux-kernel.html Holy crap! That seems to work!!!! Im getting ~75MB/s transfers on a 130GB file. Its at 10GB and still going. THANK YOU!!!!!!!!
January 15, 201313 yr Had a quick read of the link but I cannot find how to enter such paramter, any chance on a quick howto ? I added an option to my syslinux.cfg: label unRAID OS (MAX 4GB RAM) kernel bzimage append mem=4095M initrd=bzroot default menu.c32 menu title Lime Technology LLC prompt 0 timeout 50 label unRAID OS menu default kernel bzimage append initrd=bzroot label unRAID OS (MAX 4GB RAM) kernel bzimage append mem=4095M initrd=bzroot label Memtest86+ kernel memtest 4096M didnt dwork for some reason.
Archived
This topic is now archived and is closed to further replies.