performance optimization 1187

Michael Heiming wrote (in part): Before you change anything, you should run some measurements to see what the bottlenecks of your present system are. If you are swapping too much (like more than a page or two a minute), you should probably install more RAM. That is the easiest thing to do. If you do no swapping, then you do not need more RAM.

Try running:

$ vmstat 5 procs memory swap io system cpu r b swpd free buff cache si so bi bo in cs us sy id wa 5 0 0 282480 490680 6551332 0 0 0 3 7 2 3 3 0 0 4 0 0 312884 490680 6551332 0 0 0 33 211 601 96 4 0 0 5 0 0 272320 490680 6552640 0 0 205 186 198 587 95 5 0 0 4 0 0 255416 490680 6552640 0 0 0 104 118 226 98 2 0 0 5 0 0 306184 490680 6601128 0 0 0 86 128 239 94 6 0 0 4 0 0 292064 490800 6600540 0 0 66 9825 271 252 88 12 0 0 4 0 0 230676 490804 6600540 0 0 0 17567 403 305 95 5 0 0

This machine is not doing anything much right now other than running 4 compute-limited (climate prediction for BOINC) processes. As you can see, there is no swapping going on, and very little IO.

If it just computes too slowly, you can either improve the programs (if you have the sources and the ability to improve them), give the process-limited process that do not matter lower priority (I run my BOINC stuff at nice level 19 so they get processors only when nothing more important needs one), or run them at different times.

If you have a mother board that accepts more processors than you have, you could add more processors. Another option is to replace the ones you have with faster ones, but usually this is a waste of time because you cannot usually put significantly faster processors in an existing motherboard.

Only if your machine is IO limited by your hard drives does it make much sense to diddle with hdparm. And even then, it is probably better to use multiple hard drives (perhaps 10,000rpm or 15,000rpm) on a SCSI controller, and to carefully allocate different parts of your data to different hard drives to reduce seek contention.

I spent several years building an optimizer for the C compiler for a large organization that produced it. We achieved many interesting improvements in end speed, especially for stupid benchmarks, but when all was said and done, if you need much improvement from your optimizer, you would be better off getting a newer faster processor. Speed improvements from automatic code improvements -- for well written programs (and these are rare) -- are seldom over 2:1, and a processor that is twice as fast is much easier to get.

Yes. I do run (IBM DB2 dbms) database software and even with that I have seen no need to tune my OS for speed. I did need to put this intoetc-sysctl.conf:

# Controls shared memory, messages, semaphors, and max open files for IBM DB2 # These added by jdbeyer. # Default msgmni (max # of msg queue identifiers) was 16: not enough. kernel.msgmni=1024 # Last item was 128: we raise to 1024. # Guessing these items are, in order: # max num of semaphores per id: 8000 MAX # semaphore maximum value: 32767 MAX # max num of ops per semop call: 1000 MAX # max # of semaphore identifiers: IPCMNI MAX (32767) kernel.sem=250 32000 32 1024

but this was so it would work at all, not for speed. The best thing for speed here was to put all the database stuff on a bunch of 10,000 rpm Ultra-320 SCSI drives and run the IO for the database stuff in raw mode. I do not know if you can do that with FC5.

For me, this reveals:

$ free -m total used free shared buffers cached Mem: 8016 7740 275 0 479 6397 --+ buffers-cache: 863 7152 Swap: 8001 0 8001

but I have 8GBytes RAM in this machine.

-- .~. Jean-David Beyer Registered Linux User 85642. V PGP-Key: 9A2FC99A Registered Machine 241939. ^^-^^ 08:10:01 up 11 days, 21:36, 3 users, load average: 4.17, 4.18, 4.18