Tool for slow OS?

your_shadow03 · 11-29-2009, 02:34 AM

I am searching for tool /script which can detect the reason of slow OS?

your_shadow03 · 11-29-2009, 02:55 AM

or if we can have some check points for checking what is making it slow.

evo2 · 11-29-2009, 04:13 AM

Poor performance is usually caused by ram overuse or harddisk disk settings. There are many articles on the web. Here is one that google provided.

http://www.linuxforums.org/articles/...uning_107.html

Have a read and try what it suggests.

Cheers,

Evo2.

salasi · 11-29-2009, 04:58 AM

Quote:

Originally Posted by your_shadow03

I am searching for tool /script which can detect the reason of slow OS?

I am afraid that the only comprehensive tool that I know for the investigation of slowness is an unpleasant, squidgy, grey thing that sits between your ears. Getting a good one of these, which really works well, is a worthwhile exercise, but does take a little time.

I have conceived of the idea of a 'little' script that goes round the various sources of information and highlights things that seem out of order, but I haven't actually done anything about that idea, and, if history is a guide, I probably never will.

your_shadow03 · 11-29-2009, 05:26 AM

Still waiting for other geeks too!!
Come on , help me out !!!

EricTRA · 11-29-2009, 05:32 AM

Hi your_shadow03,

Have you read the article the link posted by evo2 provides? There's some pretty good info and tool explanation in there. I'd suggest also you first read that one, use those tools pointed out in there and see if it makes any difference or if at least you can pinpoint what's slowing down your OS.

If you can pinpoint it, then a solution is a lot closer.

Kind regards,

Eric

i92guboj · 11-29-2009, 05:39 AM

First, define "slow". That can mean a lot of things, describe the symptoms you are experiencing.

brianL · 11-29-2009, 05:44 AM

Yes, definitely a bit vague. Slow doing what? Compared to what: another machine, a benchmark? Or are you just impatient?

your_shadow03 · 11-29-2009, 10:21 PM

By slow, I mean developers are finding slow during logging in, runnign the application, the output gets displayed late etc etc

i92guboj · 11-29-2009, 10:30 PM

Still a bit vague, let's see...

Quote:

Originally Posted by your_shadow03

By slow, I mean developers are finding slow during logging in

How are they logging in? Are them logging into locally or via network? Are they logging in into a full blown desktop or in command line?

There could be all kind of issues here, ranging from network related problems to hardware problems, or simply a distro that's not suited for your hardware.

Quote:

runnign the application, the output gets displayed late etc etc

Try monitoring your ram usage, and look very carefully at the swap usage and the disk activity while operating. Check also that you are using the right driver for your video card, and if your disks are non-SATA, check that you are using the right driver and that your UDMA is enabled.

Try these:

Code:

$ glxinfo | head
# change sda by whatever your main disk drive is
$ hdparm -tT /dev/sda
$hdparm -cdi /dev/sda
# run this one when your system starts becoming unresponsive
# or whatever problem you are experiencing, so we can see
# if it's your ram the problem
$ free

If you are using remote logins, you should also try to ping your box from the remote one and see if there's any kind of latency issue.

itsbrad212 · 11-30-2009, 12:03 AM

What distribution are you using? I have found that ext4 works better and faster than the past ext's and lvm.

Also, from my experience, the CPU has more effect on the speed then the memory. You may want to upgrade the cpu and make sure your motherboard has support for it ^^

i92guboj · 11-30-2009, 12:18 AM

Quote:

Originally Posted by itsbrad212

What distribution are you using? I have found that ext4 works better and faster than the past ext's and lvm.

Better? yes, probably. Significant? well, most times it's not. In any case, if there's a serious performance problem, ext3 vs ext4 will not fix anything. LVM is not a file system either, it's just a convenient way to manage logical volumes providing capabilities that old fs's lack, like live snapshots or on the fly resizing etc. LVM volumes will be formated with ext3/2, ext4, reiserfs or whatever you prefer, just like regular partitions, so using LVM or not is irrelevant.

Quote:

Also, from my experience, the CPU has more effect on the speed then the memory.

Then you never ran out of ram. When you start swapping heavily because you are out of ram the performance drops by several orders of magnitude, making it completely impossible to operate until the kernel can find enough cpu cycles for the OOM killer to run and kill the offending process, and that only after the swap has filled, which can take enormous amounts of time.

Where the bottleneck will like will only depends on the task at hand of course, which is why I asked for more info on first place, because the thread is quite vague. But suggesting to upgrade the cpu as the solution when we don't even know where the problem lies is maybe not the best option.

itsbrad212 · 11-30-2009, 12:35 AM

Quote:

Originally Posted by i92guboj

Better? yes, probably. Significant? well, most times it's not. In any case, if there's a serious performance problem, ext3 vs ext4 will not fix anything. LVM is not a file system either, it's just a convenient way to manage logical volumes providing capabilities that old fs's lack, like live snapshots or on the fly resizing etc. LVM volumes will be formated with ext3/2, ext4, reiserfs or whatever you prefer, just like regular partitions, so using LVM or not is irrelevant.

Then you never ran out of ram. When you start swapping heavily because you are out of ram the performance drops by several orders of magnitude, making it completely impossible to operate until the kernel can find enough cpu cycles for the OOM killer to run and kill the offending process, and that only after the swap has filled, which can take enormous amounts of time.

Where the bottleneck will like will only depends on the task at hand of course, which is why I asked for more info on first place, because the thread is quite vague. But suggesting to upgrade the cpu as the solution when we don't even know where the problem lies is maybe not the best option.

Well, when I was in gparted, it showed LVM2 as the filesystem. So I take it that gparted is incorrect? I originally had fedora 12 on lvm2, as gparted said, so I installed it on ext4 and it was SUPER FAST. And I don't recall saying that upgrading the CPU was exactly the solution to his problem. I gave my opinion on the fact because in a post, evo2 said that the problem is ram, but you can just reboot the machine and every thing's dandy. I would really like to have the author of this thread give us a better description on the "slow" problem. For example: it could be a desktop environment that uses alot of resources, like kde and gnome, as opposed to xfce and fluxbox.

i92guboj · 11-30-2009, 01:26 AM

Quote:

Originally Posted by itsbrad212

Well, when I was in gparted, it showed LVM2 as the filesystem.

gparted doesn't support lvm at all, that's why it won't show any fs inside an lvm partition. All it does is to display the LVM label so you know that, but nothing else. It's one of the features I'd like to see in gparted because there's really no decent GUI for the LVM tools, however the command line ones are easy to deal with and work well.

http://gparted.sourceforge.net/features.php

In that table it shows that gparted can only detect LVM groups, but it will not show the fs('s) inside it, nor can do it any other thing. You can think of it as a partition containing partitions, each of which can have a different format. So, on a single LVM volume group you can have lots of different pieces with different formats.

It all is a bit confusing if you have no experience with it because it's not the typical setup you find in other OSes, but there are good manuals around. Once you understand the terminology LVM is much more clear, but that exceeds the purpose of this thread by far.

smeezekitty · 11-30-2009, 01:53 AM

type more /proc/meminfo and post the output