Date: Thu, 25 Aug 2005 13:39:25 -0500 From: Mark Kane <mark@mkproductions.org> To: Roland Smith <rsmith@xs4all.nl> Cc: freebsd-questions@freebsd.org Subject: Re: Performance Issues with AMD64 3000+, 1.5GB RAM, FreeBSD 5.4-RELEASE Message-ID: <430E105D.3080509@mkproductions.org> In-Reply-To: <20050825181931.GE10790@slackbox.xs4all.nl> References: <430D3823.9070301@mkproductions.org> <20050825160909.GB10134@slackbox.xs4all.nl> <430DF015.5000203@mkproductions.org> <20050825173758.GA10790@slackbox.xs4all.nl> <430E0461.3030101@mkproductions.org> <20050825181931.GE10790@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Roland Smith wrote:
>>So you have no similar problems in -STABLE? How about when untarring a
>>bigger file and playing audio? If not, then maybe trying STABLE on that
>>other drive might be a good idea.
>
>
> Yesterday I was making a level 0 dump of my /usr partition (32429 MB) to
> another drive, which was being compressed with bzip2. CPU usage was
> around 97% [for bzip2], but I didn't notice anything. While the dump was
> underway, I was browsing with Firefox, and writing in emacs.
Wow, that would be really nice. I notice whenever I compress something
like a backup of my Thunderbird Inbox files (several hundred megs) in
bzip2 format it goes nowhere near 100% or even 90% CPU usage. The
problems I am talking about occur even when CPU usage is real low as
well. :-\
>>The reason I wanted to see any changelog was to see if there is any
>>changes to this part of the code at all before trying it, but file by
>>file I would probably be lost since I am not a programmer.
>
>
> The file is the most usual way to partition code. How else would you
> know where to look?
True. I meant I wouldn't know what files to look at since I don't know
really anything about programming or how things are done internally. I'm
kind of used to the subversion approach of revisions for everything
instead of file by file. Then it would have one log showing all the
changes of that revision all in one place. I see how the other way makes
sense though.
> Some other thing you might look at is if too many devices are sharing an
> interrupt. Try ps -xa|grep '\[irq.*\]' If so, that might give problems,
> I think. Anything in the logfiles?
[mixx941@amd64:~]% ps -xa|grep '\[irq.*\]'
12 ?? WL 0:05.59 [irq1: atkbd0]
13 ?? WL 0:00.00 [irq3: sio1]
14 ?? WL 0:00.00 [irq4: sio0]
15 ?? WL 0:00.00 [irq5:]
16 ?? WL 0:00.00 [irq6: fdc0]
17 ?? WL 0:00.00 [irq7: ppc0]
18 ?? WL 0:00.00 [irq8: rtc]
19 ?? WL 0:00.00 [irq9: acpi0]
20 ?? WL 0:00.00 [irq10:]
21 ?? WL 0:00.00 [irq11:]
22 ?? WL 1:03.19 [irq12: psm0]
23 ?? WL 0:00.00 [irq13:]
24 ?? WL 0:01.84 [irq14: ata0]
25 ?? WL 0:00.00 [irq15: ata1]
26 ?? WL 0:04.11 [irq16: atapci3]
27 ?? WL 1:13.49 [irq17: pcm0]
28 ?? WL 0:00.00 [irq18: fwohci0+]
29 ?? WL 1:35.00 [irq19: skc0 atapci2]
30 ?? WL 0:00.00 [irq20:]
31 ?? WL 0:00.00 [irq21: ohci1]
32 ?? WL 0:00.00 [irq22: ohci0+]
33 ?? WL 0:00.00 [irq23:]
34 ?? WL 0:00.00 [irq0: clk]
I don't see anything in /var/log/messages or any errors in dmesg.
-Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?430E105D.3080509>