![]() |
I missed that.
Some observations: You are using a lot of apps that are leaky and eat up a lot of RAM. I would never run all of those at once. From what I see above, I think some part of XFCE may be leaking as well as Firefox (update to latest version). Maybe try another desktop environment other than XFCE. |
1 Attachment(s)
Regarding the RAM settings, here are the outputs that I know about, to see what's happening. If you could take a minute and confirm that everything matches. These are all taken within a few seconds of each other:
htop. What I find odd is that the bars for Mem shouldn't be so far across. 2566 is 78% of 3271. There are 30 bars and so 78% of those is 23. In the attached PNG you can see that they are ALL lit up. Here is the text version: Code:
1 [|| 4.6%] Tasks: 114, 56 kthr; 1 running Code:
top - 16:48:13 up 1 day, 19:42, 4 users, load average: 0.05, 0.03, 0.05 Code:
[fred@arch ~]$ free Code:
[fred@arch ~]$ sudo ps_mem |
Quote:
I thought 4G (even 3.5) was a lot and it could handle all this. Maybe I am wrong. Your point about Xfce is interesting and pre-empts my previous post where I mentioned the CPU monitor (we posted simultaneously it seems) and I suppose that to try another DE is actually a very good idea. I could try and see what happens. |
Firefox is the main issue I think. Maybe try removing plugins or extensions that you don't need.
|
Here's another thing to try:
Code:
echo 1 > /proc/sys/vm/dirty_background_ratio I'll experiment with some options to try and solve the issue. Probably a definitive solution is more RAM. Also see: http://www.westnet.com/~gsmith/conte...ux-pdflush.htm http://kmaiti.blogspot.com/2011/09/c...cache-and.html |
I got a 500 G USB and put on it a swap partition. I tried adding it in /etc/fstab but I failed. So now I have no swap at all, temporarily.
I rebooted and when I just launch a few apps on my fresh Xfce desktop, I hear the disk drive grinding already. I opened up a terminal and htop said 400/3271MB and then 720/3271MB when all 6 apps were launched. And this is without Firefox. :) My point is that the disk is grinding and there's LOTS of free RAM. That's how it apears to me anyhow. If I open Thunar and browse to /srv/http and then click the little icon to show all the directories in the left sidebar, I hear the disk grind for 3 seconds before it finishes and shows the directories. There are 44 directories plus 69 files in this /srv/http . Seems bizarre that it should grind, and this with 1450/3271MB Mem in htop. This grinding has nothing to do with RAM nor swap, as far as I can see. I ran echo 1 > /proc/sys/vm/dirty_background_ratio and then played with Thunar and it still grinds. So on the one hand, this seems unrelated. This setting is a RAM paging issue and I am testing disk read I guess. But perhaps the above demonstrates that just reading from the disk is NOT working as it should. Because the physical RAM is not even 1/3 in use. Now I figured out how to manually add the swap partition so I have Code:
$ free -m I am confused and quite discouraged. Unless I am misunderstanding something, this is not a RAM problem, because I am seeing slowness and grinding with NO swap being used or with SWAP on a separate physical machine. Here is another experiment, a somewhat scientific one. I made a bash script: Code:
#!/bin/bash Code:
$ ./lines.sh I unfortunately don't have any other ideas for clear tests to run. I have only two ideas left: 1. Use PAE Kernel, but this will only gain me 0.5 G physical RAM and so I don't see much reason to think it will fix my other problems 2. Reinstall using 64 bit Kernel, perhaps on a different drive. Truth is this is already a replacement drive, but I used Clonezilla to copy from the old one and maybe there is something wrong with the setup or partitions. Don't know what, but maybe. I could try a brand new install on a separate disk and then have both disks in the same PC and see if it helps... |
Maybe there are a lot of fragmented files. If you want, I wrote an experimental defrag script that you can try, it is on my site.
http://htexmexh.my3gb.com/linux/scripts.html |
Doesn't seem like it found much:
Code:
$ sudo ./localfinddefrag |
Quote:
Code:
Wed Dec 28 18:41:34 CET 2011 |
It takes longer than 3 minutes on my netbook. I didn't wait for it, because it was taking too long.
|
I tried that on an old (hardware and software) Centos system that I happened to have a putty window open on and that was otherwise idle. It took 129 seconds. But then I realized my home directory there is an NFS mount, which makes exactly this kind of file I/O much slower than local (even though the LAN is 1Gb and the file server super fast RAID and heavily cached with ram and lightly loaded.)
So I switched to a local directory and tried it. That took 103 seconds. I was curious how much of that time was disk I/O, so I switched to a directory on a tmpfs (with enough free ram that this test wouldn't cause tmpfs to use any SWAP) and the test took 88 seconds. I don't really understand my middle result. I expect write behind caching to be very limited when using NFS, so the extra time there is reasonable for lots of waits for short messages across the LAN. But I expected writes to a local disk file (on a system with lots of free ram) would just go into "write behind caching" and be nearly as fast as ram. The actual disk writes should occur after the script thinks it is done. |
Quote:
Then 1111 through 1901 are ~/.wine/drive_c/ 2162 - 9835 are ~/.thumbnails/ Lots from my Trash, too. In the end there are 357120 lines. The file is 34 MB. Perhaps that IS a lot actually. Most are "2 extents found, perfection would be 1 extent" A few are 3, 4 and 5, but just browsing through I don't see any bigger numbers than that. |
Fragmentation doesn't seem to be a problem. I never get 1, in fact I'm happy with 20-40 extents.
It must be something else. Here, I ran the script: Code:
bash-4.1$ ./test |
I would uses sysbench for more benchmarks:
http://sourceforge.net/projects/sysbench/ You may need to replace 'AC_PROG_LIBTOOL' with 'AC_PROG_RANLIB' in configure.ac and run 'autoconf' and './augen.sh' again for it to compile. Your script uses a lot of CPU usage, so it may actually be testing how good your CPU is. |
I installed sysbench 0.4.12-1, a build for ArchLinux so I presume it matches my setup.
Using this bash script: Code:
date Code:
$ ./mysysb.sh Code:
date Code:
$ ./mysysb.sh Then I tried Code:
$ sysbench --test=memory --memory-block-size=16K --memory-total-size=100G --memory-scope=global --memory-hugetlb=off --memory-oper=write --memory-access-mode=seq run Now here http://forums.tabcrawler.com/index.php?topic=4933.0 (another random page) I did this: Code:
$ sysbench --test=cpu --cpu-max-prime=20000 run |
All times are GMT -5. The time now is 05:52 AM. |