search for: elvtun

Our Invoice posting routine (intensive harddrive io) freezes every few seconds to flush the cache. Reading this: https://listman.redhat.com/archives/ext3-users/2002-November/msg00070.html I decided to try: # elvtune -r 2048 -w 131072 /dev/sda # echo "90 500 0 0 600000 600000 95 20 0" >/proc/sys/vm/bdflush # run_post_routine # elvtune -r 128 -w 512 /dev/sda # echo "30 500 0 0 500 3000 60 20 0" >/proc/sys/vm/bdflush # sync I like it, but I think that's way too lax and risky - the...

Can anyone explain how the disk elevator works and if there is anyway to tweak it? I have an email server which likely has a large number of read and write requests and was wandering if there was anyway to improve performance. Matt

...ity the machine becomes Very Slow, (e.g. takes 30-45 seconds to get a reply from ls at the console, or a minute to log in.) I experimented with data=journal, and that made the box more responsive to other new processes, but naturally the io rate fell through the floor. Also experimented with the elvtune, and we got very improved results for our tests (mainly scripts of dd, cp, and diff) but then apps (like tar) suffered. (used elvtune -r 32 -w 32 gave the best numbers on the test scripts). The best we can tell, the processing subsystem of the server is is way to fast for this relatively slow...

Hi, I'd like to use a flash drive as a journal device, with the purpose of keeping the main disk drive spun down as long as possible. I have a couple of questions: 1) Does the journaling code spread write accesses to the journal device evenly, as I hope, or are there blocks that are particularly "hot"? I.e., do I have to worry about the flash device dying quickly because of

...407.74 17.27 203.87 22.63 avgqu-sz await svctm %util 1.28 65.38 5.10 9.97 Is it normal for the %util to be 9.97% for the above reads/ writes on a U320 drive? or perhaps i have a badly misconfigured server? the drive is 2 x 146GB, RAID 1 using the LSI logic LSI22320-R card. #elvtune /dev/sda /dev/sda elevator ID 1 read_latency: 2048 write_latency: 8192 max_bomb_segments: 6 #cat /proc/sys/vm/bdflush 80 50 0 0 600 10000 80 70 0 Server is running CentOS 3.5; CPU and RAM are very m...

...until finally the server becomes unusable. A simple reboot, even with a forced fsck, does NOT clear this up, but a full shutdown followed by power cycling the RAID device and then rebooting, seems to return things to normal. After doing some research when this most recently happened, we have used elvtune to lower the read and write latency on /dev/sda4 (which is the primary filesystem on the RAID) to 128 and 256 respectively. However, we don't yet know whether this will make any difference, as it has only been 48 hours since the power cycle and it usually takes months for the problem to become...

I'm lacking some understanding of how to tune / when to tune /proc/sys/vm/bdflush Where can I read up on this? Our current problem: Load is low, but ever so often the system decides to do some serious disk I/O which causes all processes to wait for disk I/O -- load explodes (rises linear up into the 20-30ies) just to fall linearly (spelling?) right after that. We think there might be some

Help solving a performance mystery would be welcome. I have two test programs: * one totally CPU bound (it just infinitely loops) * the other I/O bound (it loops, each time doing * a write, * an fsync or fdatasync (I get similar behavior with either), * an lseek to back up to the same position again Under ext2, if I run these two together, they each run nearly as fast as