[OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Gernot Wolf
gw.inet at chello.at
Thu Oct 20 20:20:10 UTC 2011
Grep output attached. Hopefully this attachement will go through ;)
Regards,
Gernot Wolf
Am 20.10.11 21:25, schrieb Michael Stapleton:
> Attachment is missing...
>
> I'd like to see the whole things, but in the mean while
>
> #grep -i acpi /var/adm/messages
>
> Anything?
>
> Mike
>
>
> On Thu, 2011-10-20 at 21:09 +0200, Gernot Wolf wrote:
>
>> You mean, besides being quite huge? I took a quick look at it, but other
>> than getting a headache by doing that, my limited unix skills
>> unfortunately fail me.
>>
>> I've zipped it an attached it to this mail, maybe someone can get
>> anything out of it...
>>
>> Regards,
>> Gernot
>>
>>
>> Am 20.10.11 20:17, schrieb Michael Schuster:
>>> Gernot,
>>>
>>> is there anything suspicious in /var/adm/messages?
>>>
>>> Michael
>>>
>>> On Thu, Oct 20, 2011 at 20:07, Michael Stapleton
>>> <michael.stapleton at techsologic.com> wrote:
>>>> That rules out userland.
>>>>
>>>> Sched tells me that it is not a user process. If kernel code is
>>>> executing on a cpu, tools will report the sched process. The count was
>>>> how many times the process was taken off the CPU while dtrace was
>>>> running.
>>>>
>>>>
>>>>
>>>> Lets see what kernel code is running the most:
>>>>
>>>> #dtrace -n 'sched:::off-cpu { @[stack()]=count()}'
>>>>
>>>> #dtrace -n 'profile-1001 { @[stack()] = count() }'
>>>>
>>>>
>>>>
>>>> On Thu, 2011-10-20 at 19:52 +0200, Gernot Wolf wrote:
>>>>
>>>>> Yeah, I've been able to run this diagnostics on another OI box (at my
>>>>> office, so much for OI not being used in production ;)), and noticed
>>>>> that there were several values that were quite different. I just don't
>>>>> have any idea on the meaning of this figures...
>>>>>
>>>>> Anyway, here are the results of the dtrace command (I executed the
>>>>> command twice, hence two result sets):
>>>>>
>>>>> gernot at tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
>>>>> dtrace: description 'sched:::off-cpu ' matched 3 probes
>>>>> ^C
>>>>>
>>>>> ipmgmtd 1
>>>>> gconfd-2 2
>>>>> gnome-settings-d 2
>>>>> idmapd 2
>>>>> inetd 2
>>>>> miniserv.pl 2
>>>>> netcfgd 2
>>>>> nscd 2
>>>>> ospm-applet 2
>>>>> ssh-agent 2
>>>>> sshd 2
>>>>> svc.startd 2
>>>>> intrd 3
>>>>> afpd 4
>>>>> mdnsd 4
>>>>> gnome-power-mana 5
>>>>> clock-applet 7
>>>>> sendmail 7
>>>>> xscreensaver 7
>>>>> fmd 9
>>>>> fsflush 11
>>>>> ntpd 11
>>>>> updatemanagernot 13
>>>>> isapython2.6 14
>>>>> devfsadm 20
>>>>> gnome-terminal 20
>>>>> dtrace 23
>>>>> mixer_applet2 25
>>>>> smbd 39
>>>>> nwam-manager 60
>>>>> svc.configd 79
>>>>> Xorg 100
>>>>> sched 394078
>>>>>
>>>>> gernot at tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
>>>>> dtrace: description 'sched:::off-cpu ' matched 3 probes
>>>>> ^C
>>>>>
>>>>> automountd 1
>>>>> ipmgmtd 1
>>>>> idmapd 2
>>>>> in.routed 2
>>>>> init 2
>>>>> miniserv.pl 2
>>>>> netcfgd 2
>>>>> ssh-agent 2
>>>>> sshd 2
>>>>> svc.startd 2
>>>>> fmd 3
>>>>> hald 3
>>>>> inetd 3
>>>>> intrd 3
>>>>> hald-addon-acpi 4
>>>>> nscd 4
>>>>> gnome-power-mana 5
>>>>> sendmail 5
>>>>> mdnsd 6
>>>>> devfsadm 8
>>>>> xscreensaver 9
>>>>> fsflush 10
>>>>> ntpd 14
>>>>> updatemanagernot 16
>>>>> mixer_applet2 21
>>>>> isapython2.6 22
>>>>> dtrace 24
>>>>> gnome-terminal 24
>>>>> smbd 39
>>>>> nwam-manager 58
>>>>> zpool-rpool 65
>>>>> svc.configd 79
>>>>> Xorg 82
>>>>> sched 369939
>>>>>
>>>>> So, quite obviously there is one executable standing out here, "sched",
>>>>> now what's the meaning of this figures?
>>>>>
>>>>> Regards,
>>>>> Gernot Wolf
>>>>>
>>>>>
>>>>> Am 20.10.11 19:22, schrieb Michael Stapleton:
>>>>>> Hi Gernot,
>>>>>>
>>>>>> You have a high context switch rate.
>>>>>>
>>>>>> try
>>>>>> #dtrace -n 'sched:::off-cpu { @[execname]=count()}'
>>>>>>
>>>>>> For a few seconds to see if you can get the name of and executable.
>>>>>>
>>>>>> Mike
>>>>>> On Thu, 2011-10-20 at 18:44 +0200, Gernot Wolf wrote:
>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I have a machine here at my home running OpenIndiana oi_151a, which
>>>>>>> serves as a NAS on my home network. The original install was OpenSolaris
>>>>>>> 2009.6 which was later upgraded to snv_134b, and recently to oi_151a.
>>>>>>>
>>>>>>> So far this OSOL (now OI) box has performed excellently, with one major
>>>>>>> exception: Sometimes, after a reboot, the cpu load was about 50-60%,
>>>>>>> although the system was doing nothing. Until recently, another reboot
>>>>>>> solved the issue.
>>>>>>>
>>>>>>> This does not work any longer. The system has always a cpu load of
>>>>>>> 50-60% when idle (and higher of course when there is actually some work
>>>>>>> to do).
>>>>>>>
>>>>>>> I've already googled the symptoms. This didn't turn up very much useful
>>>>>>> info, and the few things I found didn't apply to my problem. Most
>>>>>>> noticably was this problem which could be solved by disabling cpupm in
>>>>>>> /etc/power.conf, but trying that didn't show any effect on my system.
>>>>>>>
>>>>>>> So I'm finally out of my depth. I have to admit that my knowledge of
>>>>>>> Unix is superficial at best, so I decided to try looking for help here.
>>>>>>>
>>>>>>> I've run several diagnostic commands like top, powertop, lockstat etc.
>>>>>>> and attached the results to this email (I've zipped the results of kstat
>>>>>>> because they were>1MB).
>>>>>>>
>>>>>>> One important thing is that when I boot into the oi_151a live dvd
>>>>>>> instead of booting into the installed system, I also get the high cpu
>>>>>>> load. I mention this because I have installed several things on my OI
>>>>>>> box like vsftpd, svn, netstat etc. I first thought that this problem
>>>>>>> might be caused by some of this extra stuff, but getting the same system
>>>>>>> when booting the live dvd ruled that out (I think).
>>>>>>>
>>>>>>> The machine is a custom build medium tower:
>>>>>>> S-775 Intel DG965WHMKR ATX mainbord
>>>>>>> Intel Core 2 Duo E4300 CPU 1.8GHz
>>>>>>> 1x IDE DVD recorder
>>>>>>> 1x IDE HD 200GB (serves as system drive)
>>>>>>> 6x SATA II 1.5TB HD (configured as zfs raidz2 array)
>>>>>>>
>>>>>>> I have to solve this problem. Although the system runs fine and
>>>>>>> absolutely serves it's purpose, having the cpu at 50-60% load constantly
>>>>>>> is a waste of energy and surely a rather unhealthy stress on the hardware.
>>>>>>>
>>>>>>> Anyone any ideas...?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gernot Wolf
>>>>>>> _______________________________________________
>>>>>>> OpenIndiana-discuss mailing list
>>>>>>> OpenIndiana-discuss at openindiana.org
>>>>>>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenIndiana-discuss mailing list
>>>>>> OpenIndiana-discuss at openindiana.org
>>>>>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenIndiana-discuss mailing list
>>>>> OpenIndiana-discuss at openindiana.org
>>>>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenIndiana-discuss mailing list
>>>> OpenIndiana-discuss at openindiana.org
>>>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> OpenIndiana-discuss mailing list
>> OpenIndiana-discuss at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>
> _______________________________________________
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss at openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: messages_apci.txt
URL: <http://openindiana.org/pipermail/openindiana-discuss/attachments/20111020/dda66b08/attachment-0001.txt>
More information about the OpenIndiana-discuss
mailing list