Re: [OpenIndiana-discuss] CIFS Alias/Multiple connections
Oh! I might have a guess what this is - but your captures will verify. You can also turn on debug logging. I think you may see that the "vc==0" feature is causing the new connection to kill the prior ones. On Thu, Oct 20, 2011 at 6:13 PM, Jonathan Leafty wrote: > No network captures yet, I was kind of waiting for the fqdn to be fixed as I > was thinking it was related. I think I'll have time to do it this weekend, > I'll load Wireshark on a Windows 7 VM and report back. > > Also, I can open two different Explorer Windows (though if you quickly > navigate against both you may notice it) with two different aliases, what > matters is data transfer. If I'm copying/reading data on alias1 and I start > another on alias2, alias1 gets disconnected. Same with writes. I can > positively say, this never occurred with OS b129-134. I first noticed it in > b134a, then Solaris 11 Express, and now OpenIndiana b151a. > > Its probably related to the various SMB changes with Windows 7/2K8 so I'll > try to spin an XP VM up too (I don't have a physical XP box anymore) > > On Thu, Oct 20, 2011 at 11:31 AM, Gordon Ross wrote: > >> On Thu, Oct 20, 2011 at 12:48 PM, Jonathan Leafty >> wrote: >> > No they're just set up in DNS. After b134 (any flavor, OpenSolaris, >> Solaris >> > 11 Express) it won't accept CIFS connections to DNS aliases. >> > >> > Windows 2008 is the same way, but you can flip a registry setting to let >> SMB >> > Connections come in on DNS Aliases even if its not set as a SPN alias >> (the >> > more proper way). >> > >> > Which brings me to another problem. I can't authenticate against the >> actual >> > AD SPN/Hostname, I get access denied. But I believe I've seen a bug >> report >> > about it. I can go to \\hostname, but not \\hostname.fqdn if I had a >> DNS >> > alias as a SPN alias, it will do the same. I haven't packet sniffed yet, >> as >> > its not a huge issue and since there was a bug report. >> >> Yes, here's the issue for that: https://www.illumos.org/issues/1087 >> Unable to connect to the CIFS server using \\servername.fqdn >> We have someone working on it. >> >> Perhaps your alias problem is related. >> >> Do you have network captures for the failure? >> Is it the session setup that fails? Tree connect? >> >> Thanks, >> Gordon >> >> ___ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS Alias/Multiple connections
No network captures yet, I was kind of waiting for the fqdn to be fixed as I was thinking it was related. I think I'll have time to do it this weekend, I'll load Wireshark on a Windows 7 VM and report back. Also, I can open two different Explorer Windows (though if you quickly navigate against both you may notice it) with two different aliases, what matters is data transfer. If I'm copying/reading data on alias1 and I start another on alias2, alias1 gets disconnected. Same with writes. I can positively say, this never occurred with OS b129-134. I first noticed it in b134a, then Solaris 11 Express, and now OpenIndiana b151a. Its probably related to the various SMB changes with Windows 7/2K8 so I'll try to spin an XP VM up too (I don't have a physical XP box anymore) On Thu, Oct 20, 2011 at 11:31 AM, Gordon Ross wrote: > On Thu, Oct 20, 2011 at 12:48 PM, Jonathan Leafty > wrote: > > No they're just set up in DNS. After b134 (any flavor, OpenSolaris, > Solaris > > 11 Express) it won't accept CIFS connections to DNS aliases. > > > > Windows 2008 is the same way, but you can flip a registry setting to let > SMB > > Connections come in on DNS Aliases even if its not set as a SPN alias > (the > > more proper way). > > > > Which brings me to another problem. I can't authenticate against the > actual > > AD SPN/Hostname, I get access denied. But I believe I've seen a bug > report > > about it. I can go to \\hostname, but not \\hostname.fqdn if I had a > DNS > > alias as a SPN alias, it will do the same. I haven't packet sniffed yet, > as > > its not a huge issue and since there was a bug report. > > Yes, here's the issue for that: https://www.illumos.org/issues/1087 > Unable to connect to the CIFS server using \\servername.fqdn > We have someone working on it. > > Perhaps your alias problem is related. > > Do you have network captures for the failure? > Is it the session setup that fails? Tree connect? > > Thanks, > Gordon > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Ok, I could not resist giving it a try, screw my bed ;)
Mike, bingo! That one hit home. With acpi-user-options set to 0x08 and
subsequent reboot cpu load is back to normal (that is load average=0.05).
I'll run my diagnostics again on my system and post the results in case
anyone is interested comparing the numbers. But that will really have to
wait for tomorrow ;)
Big thanks to all of you, you guys have been amazing! Your help is very
much appreciated :)
Regards,
Gernot Wolf
Am 20.10.11 21:55, schrieb Michael Stapleton:
Probably just too big.
Are there any ACPI settings in the BIOS?
or we can try to change ACPI in OI.
#man eeprom
.
.
.
OPERANDS
x86 Only
acpi-user-options
A configuration variable that controls the use of
Advanced Configuration and Power Interface (ACPI), a
power management specification. The acceptable values
for this variable depend on the release of the Solaris
operating system you are using.
For all releases of Solaris 10 and Solaris 11, a value
of of 0x0 means that there will be an attempt to use
ACPI if it is available on the system. A value of 0x2
disables the use of ACPI.
For the Solaris 10 1/06 release, a value of 0x8 means
that there will be an attempt to use ACPI in a mode com-
patible with previous releases of Solaris 10 if it is
available on the system. The default for Solaris 10 1/06
is 0x8.
For releases of Solaris 10 after the 1/06 release and
for Solaris 11, the default is 0x0.
Most users can safely accept the default value, which
enables ACPI if available. If issues related to the use
of ACPI are suspected on releases of Solaris after
Solaris 1/06, it is suggested to first try a value of
0x8 and then, if you do not obtain satisfactory results,
0x02.
Want to try:
#eeprom acpi-user-options=0x8
# init 6
?
If you have booting problems after changes, the following link will
help:
Boot Arguments You Can Specify When Editing the GRUB Menu at Boot Time
-B acpi-user-options=0x2
Disables ACPI entirely.
http://dlc.sun.com/osol/docs/content/SYSADV1/getov.html
Mike
On Thu, 2011-10-20 at 21:37 +0200, Gernot Wolf wrote:
Ok, for some reason this attachement refuses to go out :( Have to figure
that out...
Regards,
Gernot Wolf
Am 20.10.11 21:20, schrieb Gernot Wolf:
Ooops, something went wrong with my attachement. I'll try again...
Regards,
Gernot Wolf
Am 20.10.11 21:09, schrieb Gernot Wolf:
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
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@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@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
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Sorry, I was away from my desk for a while. Obviously this isn't an issue,
in fact, if anything, those numbers are surprisingly small.
On Thu, Oct 20, 2011 at 12:18 PM, Gernot Wolf wrote:
> Here are the results (let the script run for a few secs):
>
> CPU IDFUNCTION:NAME
> 1 2 :END DEVICE TIME (ns)
> i9151 22111
> heci0 23119
> pci-ide0 38700
> uhci1 47277
> hci13940 50554
> uhci3 63145
> uhci0 64232
> uhci4 103429
> ehci1 107272
> ehci0 108445
> uhci2 112589
>e1000g0 160024
>
> Regards,
> Gernot Wolf
>
>
> Am 20.10.11 20:22, schrieb Rennie Allen:
>
>> Try the following script, which will identify any drivers with high
>> interrupt load
>>
>> -
>> #!/usr/sbin/dtrace -s
>>
>> sdt:::interrupt-start { self->ts = vtimestamp; }
>> sdt:::interrupt-complete
>> /self->ts&& arg0 != 0/
>>
>> {
>> this->devi = (struct dev_info *)arg0;
>> self->name = this->devi != 0 ?
>> stringof(`devnamesp[this->**devi->devi_major].dn_name) : "?";
>> this->inst = this->devi != 0 ? this->devi->devi_instance : 0;
>> @num[self->name, this->inst] = sum(vtimestamp - self->ts);
>> self->name = 0;
>> }
>> sdt:::interrupt-complete { self->ts = 0; }
>> dtrace:::END
>> {
>> printf("%11s%16s\n", "DEVICE", "TIME (ns)");
>> printa("%10s%-3d %@16d\n", @num);
>> }
>> -
>>
>>
>>
>>
>>
>> On 10/20/11 11:07 AM, "Michael Stapleton"
>> >
>> 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@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
idmapd2
inetd 2
miniserv.pl 2
netcfgd 2
nscd 2
ospm-applet 2
ssh-agent 2
sshd 2
svc.startd2
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_applet225
smbd 39
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Just checking ;-)
Night!
Mike
On Thu, 2011-10-20 at 22:40 +0200, Gernot Wolf wrote:
> No. Why?
>
> Regards,
> Gernot Wolf
>
>
> Am 20.10.11 22:33, schrieb Michael Stapleton:
> > Is this running in a VM?
> >
> > Mike
> >
> > On Thu, 2011-10-20 at 22:20 +0200, Gernot Wolf wrote:
> >
> >> 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
> > 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@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
> >
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Ok, I'll try that tomorrow. Too late to try anything that might result
in my box having booting problems ;)
Regards,
Gernot Wolf
Am 20.10.11 21:55, schrieb Michael Stapleton:
Probably just too big.
Are there any ACPI settings in the BIOS?
or we can try to change ACPI in OI.
#man eeprom
.
.
.
OPERANDS
x86 Only
acpi-user-options
A configuration variable that controls the use of
Advanced Configuration and Power Interface (ACPI), a
power management specification. The acceptable values
for this variable depend on the release of the Solaris
operating system you are using.
For all releases of Solaris 10 and Solaris 11, a value
of of 0x0 means that there will be an attempt to use
ACPI if it is available on the system. A value of 0x2
disables the use of ACPI.
For the Solaris 10 1/06 release, a value of 0x8 means
that there will be an attempt to use ACPI in a mode com-
patible with previous releases of Solaris 10 if it is
available on the system. The default for Solaris 10 1/06
is 0x8.
For releases of Solaris 10 after the 1/06 release and
for Solaris 11, the default is 0x0.
Most users can safely accept the default value, which
enables ACPI if available. If issues related to the use
of ACPI are suspected on releases of Solaris after
Solaris 1/06, it is suggested to first try a value of
0x8 and then, if you do not obtain satisfactory results,
0x02.
Want to try:
#eeprom acpi-user-options=0x8
# init 6
?
If you have booting problems after changes, the following link will
help:
Boot Arguments You Can Specify When Editing the GRUB Menu at Boot Time
-B acpi-user-options=0x2
Disables ACPI entirely.
http://dlc.sun.com/osol/docs/content/SYSADV1/getov.html
Mike
On Thu, 2011-10-20 at 21:37 +0200, Gernot Wolf wrote:
Ok, for some reason this attachement refuses to go out :( Have to figure
that out...
Regards,
Gernot Wolf
Am 20.10.11 21:20, schrieb Gernot Wolf:
Ooops, something went wrong with my attachement. I'll try again...
Regards,
Gernot Wolf
Am 20.10.11 21:09, schrieb Gernot Wolf:
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
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@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@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.
M
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
No. Why?
Regards,
Gernot Wolf
Am 20.10.11 22:33, schrieb Michael Stapleton:
Is this running in a VM?
Mike
On Thu, 2011-10-20 at 22:20 +0200, Gernot Wolf wrote:
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
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@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
idmapd2
inetd 2
miniserv.pl 2
netcfgd 2
nscd 2
ospm-applet 2
ssh-agent 2
sshd 2
svc.startd2
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_applet225
smbd 39
nwam-manager 60
svc.configd 79
Xorg100
sched394078
gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
dtrace: description 'sched:::off-cpu ' matched 3 probes
^C
automountd1
ipmgmtd 1
idmapd2
in.routed 2
init 2
miniserv.pl 2
netcfgd 2
ssh-agent
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Yes, I noticed that to when I compared the lockstat output on my OI box with that on the OI box at my office. There no Acpi debug tracing functions are shown at all... Mike made further suggestions concerning apci, but that will have to wait for tomorrow. My bed is calling my name ;) Regards, Gernot Wolf Am 20.10.11 19:55, schrieb Steve Gonczi: Your lockstat output fingers Acpi debug tracing functions. I wonder why these are running in the first place. Steve - Original Message - Hello all, I have a machine here at my home running OpenIndiana oi_151a, which serves as a NAS on my home network. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Is this running in a VM?
Mike
On Thu, 2011-10-20 at 22:20 +0200, Gernot Wolf wrote:
> 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
> >>>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@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
> > idmapd2
> > inetd 2
> > miniserv.pl 2
> > netcfgd 2
> > nscd 2
> > ospm-applet 2
> > ssh-agent 2
> > sshd 2
> > svc.startd2
> > 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_applet225
> > smbd 39
> > nwam-manager 60
> > svc.configd 79
> > Xorg100
> > sched394078
> >
> > gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
> > dtrace: description 'sched:::off-cpu ' matched 3 probe
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
I would not worry about it. The messages are being caused by some problem. Lets focus on getting the messages. Debug will increase your load, but not like you are seeing. Mike On Thu, 2011-10-20 at 22:10 +0200, Gernot Wolf wrote: > Ok, here we go: > > gernot@tintenfass:~# mdb -k > Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc > pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba uhci s1394 fctl > stmf_sbd stmf idm fcip cpc random sata crypto sd lofs logindmux ptm ufs > sppp smbsrv nfs ipc ] > > AcpiDbgLevel > > AcpiDbgLevel/x > AcpiDbgLevel: > AcpiDbgLevel: 0 > > q > mdb: failed to dereference symbol: unknown symbol name > > $q > > So, ApciDbgLevel seems to be 0??? Now I'm getting confused... shouldn't > that mean no Apci debug function calls at all? > > Regards, > Gernot Wolf > > > Am 20.10.11 21:21, schrieb Steve Gonczi: > > Here is something to check: > > > > Pop into the debugger ( mdb -k) and see what AcpiDbgLevel's current setting > > is. > > > > E.g: > > > > AcpiDbgLevel/x > > > > The default setting is 3. If its something higher, that would explain the > > high incidence of > > Acpi trace/debug calls. > > > > To exit the debugger type $q or ::quit > > > > > > Steve > > > > > > > > - Original Message - > > 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 > > > > > > ___ > > OpenIndiana-discuss mailing list > > OpenIndiana-discuss@openindiana.org > > http://openindiana.org/mailman/listinfo/openindiana-discuss > > ___ > > OpenIndiana-discuss mailing list > > OpenIndiana-discuss@openindiana.org > > http://openindiana.org/mailman/listinfo/openindiana-discuss > > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Ok, here we go: gernot@tintenfass:~# mdb -k Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba uhci s1394 fctl stmf_sbd stmf idm fcip cpc random sata crypto sd lofs logindmux ptm ufs sppp smbsrv nfs ipc ] > AcpiDbgLevel > AcpiDbgLevel/x AcpiDbgLevel: AcpiDbgLevel: 0 > q mdb: failed to dereference symbol: unknown symbol name > $q So, ApciDbgLevel seems to be 0??? Now I'm getting confused... shouldn't that mean no Apci debug function calls at all? Regards, Gernot Wolf Am 20.10.11 21:21, schrieb Steve Gonczi: Here is something to check: Pop into the debugger ( mdb -k) and see what AcpiDbgLevel's current setting is. E.g: AcpiDbgLevel/x The default setting is 3. If its something higher, that would explain the high incidence of Acpi trace/debug calls. To exit the debugger type $q or ::quit Steve - Original Message - 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 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Well, I zipped it, the zipfile is just 211K? Shouldn't be a problem, I think... Regards, Gernot Wolf Am 20.10.11 21:38, schrieb James Carlson: Gernot Wolf wrote: Ok, for some reason this attachement refuses to go out :( Have to figure that out... Probably just because it's huge. Try "tail -100 /var/adm/messages". It's likely that if there's something going nuts on your system, there'll be enough log-spam to identify it. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Am 20.10.11 20:57, schrieb Michael Schuster: On Thu, Oct 20, 2011 at 20:55, Michael Stapleton wrote: You might be right. But 45% of what? Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec) Count indv cuml rcnt nsec Hottest CPU+PIL Caller --- 2649 45% 45% 0.00 1070 cpu[1] i86_mwait 358 6% 51% 0.00 963 cpu[0] AcpiDebugPrint 333 6% 57% 0.00 960 cpu[0] AcpiUtTrackStackPtr 2649 times in 30 seconds totaling 1070 ns does not seem like much to me. My idle laptop shows: Count indv cuml rcnt nsec Hottest CPU+PIL Caller --- 5441 93% 93% 0.00 3132 cpu[0] i86_mwait hmm ... good point. Gernot? ;-) ...slowly catching up... ;) I ran the lockstat command on the OI box at my office, just to have another set of numbers to compare. Output: admin@victor:~# lockstat -kIW -D 20 sleep 30 Profiling interrupt: 2930 events in 30.208 seconds (97 events/sec) Count indv cuml rcnt nsec Hottest CPU+PILCaller --- 2882 98% 98% 0.00 2035 cpu[0] mach_cpu_idle 10 0% 99% 0.00 8696 cpu[0] (usermode) 5 0% 99% 0.00 4738 cpu[0] mutex_enter 5 0% 99% 0.00 9502 cpu[0] lzjb_compress 1 0% 99% 0.00 2647 cpu[0] vsd_free 1 0% 99% 0.00 7323 cpu[0] vn_rele_dnlc 1 0% 99% 0.0011953 cpu[0] vmem_xfree 1 0% 99% 0.0016401 cpu[0] kmem_partial_slab_cmp 1 0% 99% 0.0013537 cpu[0] list_remove 1 0% 99% 0.0013100 cpu[0] copy_pattern 1 0% 99% 0.00 2154 cpu[0]+11 disp_lock_enter_high 1 0% 99% 0.00 2098 cpu[0] avl_destroy_nodes 1 0% 99% 0.00 9981 cpu[0] avl_find 1 0% 99% 0.0012003 cpu[0] avl_rotation 1 0% 99% 0.00 1933 cpu[0]+11 pg_ev_thread_swtch 1 0% 99% 0.0012921 cpu[0] rw_enter 1 0% 99% 0.0015171 cpu[0] rw_destroy 1 0% 100% 0.00 8611 cpu[0] page_lookup_create 1 0% 100% 0.0012249 cpu[0] mutex_exit 1 0% 100% 0.0011927 cpu[0] mutex_tryenter --- So it seems to be normal to have some kind of idle process on top. Numbers seem to be roughly comparable...? However, compared to the lockstat output of my box, there isn't anything with apci here... Regards, Gernot Wolf ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Probably just too big.
Are there any ACPI settings in the BIOS?
or we can try to change ACPI in OI.
#man eeprom
.
.
.
OPERANDS
x86 Only
acpi-user-options
A configuration variable that controls the use of
Advanced Configuration and Power Interface (ACPI), a
power management specification. The acceptable values
for this variable depend on the release of the Solaris
operating system you are using.
For all releases of Solaris 10 and Solaris 11, a value
of of 0x0 means that there will be an attempt to use
ACPI if it is available on the system. A value of 0x2
disables the use of ACPI.
For the Solaris 10 1/06 release, a value of 0x8 means
that there will be an attempt to use ACPI in a mode com-
patible with previous releases of Solaris 10 if it is
available on the system. The default for Solaris 10 1/06
is 0x8.
For releases of Solaris 10 after the 1/06 release and
for Solaris 11, the default is 0x0.
Most users can safely accept the default value, which
enables ACPI if available. If issues related to the use
of ACPI are suspected on releases of Solaris after
Solaris 1/06, it is suggested to first try a value of
0x8 and then, if you do not obtain satisfactory results,
0x02.
Want to try:
#eeprom acpi-user-options=0x8
# init 6
?
If you have booting problems after changes, the following link will
help:
Boot Arguments You Can Specify When Editing the GRUB Menu at Boot Time
-B acpi-user-options=0x2
Disables ACPI entirely.
http://dlc.sun.com/osol/docs/content/SYSADV1/getov.html
Mike
On Thu, 2011-10-20 at 21:37 +0200, Gernot Wolf wrote:
> Ok, for some reason this attachement refuses to go out :( Have to figure
> that out...
>
> Regards,
> Gernot Wolf
>
>
> Am 20.10.11 21:20, schrieb Gernot Wolf:
> > Ooops, something went wrong with my attachement. I'll try again...
> >
> > Regards,
> > Gernot Wolf
> >
> >
> > Am 20.10.11 21:09, schrieb Gernot Wolf:
> >> 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
> >>> 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@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@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
> >
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Results are up, see other post...
Regards,
Gernot Wolf
Am 20.10.11 21:00, schrieb Michael Stapleton:
+1
Mike
On Thu, 2011-10-20 at 11:47 -0700, Rennie Allen wrote:
I'd like to see a run of the script I sent earlier. I don't trust
intrstat (not for any particular reason, other than that I have never used
it)...
On 10/20/11 11:33 AM, "Michael Stapleton"
wrote:
Don't know. I don't like to trouble shoot by guess if possible. I rather
follow the evidence to capture the culprit. Use what we know to discover
what we do not know.
We know CS rate in vmstat is high, we know Sys time is high, we know
syscall rate is low, we know it is not a user process therefor it is
kernel. Likely a driver.
So what kernel code is running the most?
What's causing that code to run?
Does that code belong to a driver?
Mike
On Thu, 2011-10-20 at 20:25 +0200, Michael Schuster wrote:
Hi,
just found this:
http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
does it help?
On Thu, Oct 20, 2011 at 20:23, Michael Stapleton
wrote:
My understanding is that it is not supposed to be a loaded system. We
want to know what the load is.
gernot@tintenfass:~# intrstat 30
device | cpu0 %tim cpu1 %tim
-+--
e1000g#0 | 1 0,0 0 0,0
ehci#0 | 0 0,0 4 0,0
ehci#1 | 3 0,0 0 0,0
hci1394#0 | 0 0,0 2 0,0
i8042#1 | 0 0,0 4 0,0
i915#1 | 0 0,0 2 0,0
pci-ide#0 |15 0,1 0 0,0
uhci#0 | 0 0,0 2 0,0
uhci#1 | 0 0,0 0 0,0
uhci#2 | 3 0,0 0 0,0
uhci#3 | 0 0,0 2 0,0
uhci#4 | 0 0,0 4 0,0
device | cpu0 %tim cpu1 %tim
-+--
e1000g#0 | 1 0,0 0 0,0
ehci#0 | 0 0,0 3 0,0
ehci#1 | 3 0,0 0 0,0
hci1394#0 | 0 0,0 1 0,0
i8042#1 | 0 0,0 6 0,0
i915#1 | 0 0,0 1 0,0
pci-ide#0 | 3 0,0 0 0,0
uhci#0 | 0 0,0 1 0,0
uhci#1 | 0 0,0 0 0,0
uhci#2 | 3 0,0 0 0,0
uhci#3 | 0 0,0 1 0,0
uhci#4 | 0 0,0 3 0,0
gernot@tintenfass:~# vmstat 5 10
kthr memorypagedisk faults
cpu
r b w swap free re mf pi po fr de sr cd s0 s1 s2 in sy cs
us
sy id
0 0 0 4243840 1145720 1 6 0 0 0 0 2 0 1 1 1 9767 121
37073 0
54 46
0 0 0 4157824 1059796 4 11 0 0 0 0 0 0 0 0 0 9752 119
37132 0
54 46
0 0 0 4157736 1059752 0 0 0 0 0 0 0 0 0 0 0 9769 113
37194 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9682 104
36941 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9769 105
37208 0
54 46
0 0 0 4157728 1059772 0 1 0 0 0 0 0 0 0 0 0 9741 159
37104 0
54 46
0 0 0 4157728 1059772 0 0 0 0 0 0 0 0 0 0 0 9695 127
36931 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9762 105
37188 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9723 102
37058 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9774 105
37263 0
54 46
Mike
On Thu, 2011-10-20 at 11:02 -0700, Rennie Allen wrote:
Sched is the scheduler itself. How long did you let this run? If
only
for a couple of seconds, then that number is high, but not
ridiculous for
a loaded system, so I think that this output rules out a high context
switch rate.
Try this command to see if some process is making an excessive
number of
syscalls:
dtrace -n 'syscall:::entry { @[execname]=count()}'
If not, then I'd try looking at interrupts...
On 10/20/11 10:52 AM, "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@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-mana
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Since Gernot is seeing the issue, maybe he wants to pitch in here? He wants, he's just having a hard time keeping up with you guys. You're so fast, I'm hopelessly lagging behind ;) Thanks a lot for all the help so far to all of you! Regards, Gernot ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Nope. Cpu load remains the same. top shows:
CPU states: 47.5% idle, 0.0% user, 52.5% kernel, 0.0% iowait, 0.0% swap
Regards,
Gernot Wolf
Am 20.10.11 20:25, schrieb Michael Schuster:
Hi,
just found this:
http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
does it help?
On Thu, Oct 20, 2011 at 20:23, Michael Stapleton
wrote:
My understanding is that it is not supposed to be a loaded system. We
want to know what the load is.
gernot@tintenfass:~# intrstat 30
device | cpu0 %tim cpu1 %tim
-+--
e1000g#0 | 1 0,0 0 0,0
ehci#0 | 0 0,0 4 0,0
ehci#1 | 3 0,0 0 0,0
hci1394#0 | 0 0,0 2 0,0
i8042#1 | 0 0,0 4 0,0
i915#1 | 0 0,0 2 0,0
pci-ide#0 |15 0,1 0 0,0
uhci#0 | 0 0,0 2 0,0
uhci#1 | 0 0,0 0 0,0
uhci#2 | 3 0,0 0 0,0
uhci#3 | 0 0,0 2 0,0
uhci#4 | 0 0,0 4 0,0
device | cpu0 %tim cpu1 %tim
-+--
e1000g#0 | 1 0,0 0 0,0
ehci#0 | 0 0,0 3 0,0
ehci#1 | 3 0,0 0 0,0
hci1394#0 | 0 0,0 1 0,0
i8042#1 | 0 0,0 6 0,0
i915#1 | 0 0,0 1 0,0
pci-ide#0 | 3 0,0 0 0,0
uhci#0 | 0 0,0 1 0,0
uhci#1 | 0 0,0 0 0,0
uhci#2 | 3 0,0 0 0,0
uhci#3 | 0 0,0 1 0,0
uhci#4 | 0 0,0 3 0,0
gernot@tintenfass:~# vmstat 5 10
kthr memorypagedisk faults
cpu
r b w swap free re mf pi po fr de sr cd s0 s1 s2 in sy cs us
sy id
0 0 0 4243840 1145720 1 6 0 0 0 0 2 0 1 1 1 9767 121 37073 0
54 46
0 0 0 4157824 1059796 4 11 0 0 0 0 0 0 0 0 0 9752 119 37132 0
54 46
0 0 0 4157736 1059752 0 0 0 0 0 0 0 0 0 0 0 9769 113 37194 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9682 104 36941 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9769 105 37208 0
54 46
0 0 0 4157728 1059772 0 1 0 0 0 0 0 0 0 0 0 9741 159 37104 0
54 46
0 0 0 4157728 1059772 0 0 0 0 0 0 0 0 0 0 0 9695 127 36931 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9762 105 37188 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9723 102 37058 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9774 105 37263 0
54 46
Mike
On Thu, 2011-10-20 at 11:02 -0700, Rennie Allen wrote:
Sched is the scheduler itself. How long did you let this run? If only
for a couple of seconds, then that number is high, but not ridiculous for
a loaded system, so I think that this output rules out a high context
switch rate.
Try this command to see if some process is making an excessive number of
syscalls:
dtrace -n 'syscall:::entry { @[execname]=count()}'
If not, then I'd try looking at interrupts...
On 10/20/11 10:52 AM, "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@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
idmapd2
inetd 2
miniserv.pl 2
netcfgd 2
nscd 2
ospm-applet 2
ssh-agent 2
sshd 2
svc.startd2
intrd 3
afpd 4
mdnsd 4
gnome-power-mana 5
clock-applet 7
sendmail
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Gernot Wolf wrote: > Ok, for some reason this attachement refuses to go out :( Have to figure > that out... Probably just because it's huge. Try "tail -100 /var/adm/messages". It's likely that if there's something going nuts on your system, there'll be enough log-spam to identify it. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Ok, for some reason this attachement refuses to go out :( Have to figure
that out...
Regards,
Gernot Wolf
Am 20.10.11 21:20, schrieb Gernot Wolf:
Ooops, something went wrong with my attachement. I'll try again...
Regards,
Gernot Wolf
Am 20.10.11 21:09, schrieb Gernot Wolf:
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
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@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@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 ener
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
I let it run (as all the other dtrace commands you guys have given me)
just for a couple of seconds. And no, it's not a loaded system, that's
the problem here. It's just a home NAS...
Here is the dtrace output:
gernot@tintenfass:/root# dtrace -n 'syscall:::entry { @[execname]=count()}'
dtrace: description 'syscall:::entry ' matched 234 probes
^C
idmapd1
inetd 1
ipmgmtd 1
netcfgd 1
svc.startd1
fmd 2
utmpd 2
cnid_dbd 3
gconfd-2 3
miniserv.pl 3
ssh-agent 4
mdnsd 9
devfsadm 12
smbd 13
gnome-power-mana 15
sshd 16
nscd 20
sendmail 20
intrd22
isapython2.6 24
updatemanagernot 24
mixer_applet248
ntpd 60
svc.configd 75
nwam-manager148
Xorg602
dtrace 3417
Regards,
Gernot
Am 20.10.11 20:02, schrieb Rennie Allen:
Sched is the scheduler itself. How long did you let this run? If only
for a couple of seconds, then that number is high, but not ridiculous for
a loaded system, so I think that this output rules out a high context
switch rate.
Try this command to see if some process is making an excessive number of
syscalls:
dtrace -n 'syscall:::entry { @[execname]=count()}'
If not, then I'd try looking at interrupts...
On 10/20/11 10:52 AM, "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@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
idmapd2
inetd 2
miniserv.pl 2
netcfgd 2
nscd 2
ospm-applet 2
ssh-agent 2
sshd 2
svc.startd2
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
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
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
> > 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@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
> >>> idmapd2
> >>> inetd 2
> >>> miniserv.pl 2
> >>> netcfgd 2
> >>> nscd 2
> >>> ospm-applet 2
> >>> ssh-agent 2
> >>> sshd 2
> >>> svc.startd2
> >>> 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_applet225
> >>> smbd 39
> >>> nwam-manager 60
> >>> svc.configd 79
> >>> Xorg100
> >>> sched394078
> >>>
> >>> gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
> >>> dtrace: description 'sched:::off-cpu ' matched 3 probes
> >>> ^C
> >>>
> >>> automountd1
> >>> ipmgmtd 1
> >>> idmapd2
> >>> in.routed 2
> >>> init 2
> >>> miniserv.pl 2
> >>> ne
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Here is something to check: Pop into the debugger ( mdb -k) and see what AcpiDbgLevel's current setting is. E.g: AcpiDbgLevel/x The default setting is 3. If its something higher, that would explain the high incidence of Acpi trace/debug calls. To exit the debugger type $q or ::quit Steve - Original Message - 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 ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Ooops, something went wrong with my attachement. I'll try again...
Regards,
Gernot Wolf
Am 20.10.11 21:09, schrieb Gernot Wolf:
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
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@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@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
___
Op
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Here are the results (let the script run for a few secs):
CPU IDFUNCTION:NAME
1 2 :END DEVICE TIME (ns)
i9151 22111
heci0 23119
pci-ide0 38700
uhci1 47277
hci13940 50554
uhci3 63145
uhci0 64232
uhci4 103429
ehci1 107272
ehci0 108445
uhci2 112589
e1000g0 160024
Regards,
Gernot Wolf
Am 20.10.11 20:22, schrieb Rennie Allen:
Try the following script, which will identify any drivers with high
interrupt load
-
#!/usr/sbin/dtrace -s
sdt:::interrupt-start { self->ts = vtimestamp; }
sdt:::interrupt-complete
/self->ts&& arg0 != 0/
{
this->devi = (struct dev_info *)arg0;
self->name = this->devi != 0 ?
stringof(`devnamesp[this->devi->devi_major].dn_name) : "?";
this->inst = this->devi != 0 ? this->devi->devi_instance : 0;
@num[self->name, this->inst] = sum(vtimestamp - self->ts);
self->name = 0;
}
sdt:::interrupt-complete { self->ts = 0; }
dtrace:::END
{
printf("%11s%16s\n", "DEVICE", "TIME (ns)");
printa("%10s%-3d %@16d\n", @num);
}
-
On 10/20/11 11:07 AM, "Michael Stapleton"
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@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
idmapd2
inetd 2
miniserv.pl 2
netcfgd 2
nscd 2
ospm-applet 2
ssh-agent 2
sshd 2
svc.startd2
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_applet225
smbd 39
nwam-manager 60
svc.configd 79
Xorg100
sched394078
gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
dtrace: description 'sched:::off-cpu ' matched 3 probes
^C
automountd1
ipmgmtd
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
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
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@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
idmapd2
inetd 2
miniserv.pl 2
netcfgd 2
nscd 2
ospm-applet 2
ssh-agent 2
sshd 2
svc.startd2
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_applet225
smbd 39
nwam-manager 60
svc.configd 79
Xorg100
sched394078
gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
dtrace: description 'sched:::off-cpu ' matched 3 probes
^C
automountd1
ipmgmtd 1
idmapd2
in.routed 2
init 2
miniserv.pl 2
netcfgd 2
ssh-agent 2
sshd 2
svc.startd2
fmd 3
hald 3
inetd 3
intrd 3
hald-addon-acpi 4
nscd
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
i86_mwait is the idle function the cpu is executing when it has nothing else to do. Basically it sleeps inside of that function. Lockstat based profiling just samples what is on cpu, so idle time shows up as some form of mwait, depending on how the bios is configured. Steve - Original Message - On Thu, Oct 20, 2011 at 20:33, Michael Stapleton if you're answering my question: I'm not guessing that much: I looked at lockstat output, and right there at the top we see i86_mwait consuming 45%(!) . ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Profiling is AFAIK statistical, so it might not show the correct number. Certainly the count of interrupts does not appear high, but if the handler is spending a long time in the interrupt... The script I sent measures the time spent in the handler (intrstat might do this as well, but I just don't know how intrstat works). On Thu, Oct 20, 2011 at 11:55 AM, Michael Stapleton < michael.staple...@techsologic.com> wrote: > You might be right. > > But 45% of what? > > Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec) > > Count indv cuml rcnt nsec Hottest CPU+PIL > Caller > > --- > 2649 45% 45% 0.00 1070 cpu[1] > i86_mwait > 358 6% 51% 0.00 963 cpu[0] > AcpiDebugPrint > 333 6% 57% 0.00 960 cpu[0] > AcpiUtTrackStackPtr > > 2649 times in 30 seconds totaling 1070 ns does not seem like much to me. > > My idle laptop shows: > > Count indv cuml rcnt nsec Hottest CPU+PIL > Caller > > --- > 5441 93% 93% 0.00 3132 cpu[0] > i86_mwait > > > Mike > > On Thu, 2011-10-20 at 20:37 +0200, Michael Schuster wrote: > > > On Thu, Oct 20, 2011 at 20:33, Michael Stapleton > > wrote: > > > Don't know. I don't like to trouble shoot by guess if possible. I > rather > > > follow the evidence to capture the culprit. Use what we know to > discover > > > what we do not know. > > > > if you're answering my question: I'm not guessing that much: I looked > > at lockstat output, and right there at the top we see i86_mwait > > consuming 45%(!) ... so, popped that into google, the link I quote is > > the first to appear, and the description matches well enough that I'd > > give it a try. > > > > Since Gernot is seeing the issue, maybe he wants to pitch in here? > > > > regards > > Michael > > > On Thu, 2011-10-20 at 20:25 +0200, Michael Schuster wrote: > > > > > >> Hi, > > >> > > >> just found this: > > >> > http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html > > >> > > >> does it help? > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > -- "I hope some animal never bores a hole in my head and lays its eggs in my brain, because later you might think you're having a good idea but it's just eggs hatching" - Jack Handy ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
+1
Mike
On Thu, 2011-10-20 at 11:47 -0700, Rennie Allen wrote:
> I'd like to see a run of the script I sent earlier. I don't trust
> intrstat (not for any particular reason, other than that I have never used
> it)...
>
>
> On 10/20/11 11:33 AM, "Michael Stapleton"
> wrote:
>
> >Don't know. I don't like to trouble shoot by guess if possible. I rather
> >follow the evidence to capture the culprit. Use what we know to discover
> >what we do not know.
> >
> >We know CS rate in vmstat is high, we know Sys time is high, we know
> >syscall rate is low, we know it is not a user process therefor it is
> >kernel. Likely a driver.
> >
> >So what kernel code is running the most?
> >
> >What's causing that code to run?
> >
> >Does that code belong to a driver?
> >
> >
> >Mike
> >
> >
> >
> >On Thu, 2011-10-20 at 20:25 +0200, Michael Schuster wrote:
> >
> >> Hi,
> >>
> >> just found this:
> >> http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
> >>
> >> does it help?
> >>
> >> On Thu, Oct 20, 2011 at 20:23, Michael Stapleton
> >> wrote:
> >> > My understanding is that it is not supposed to be a loaded system. We
> >> > want to know what the load is.
> >> >
> >> >
> >> > gernot@tintenfass:~# intrstat 30
> >> >
> >> > device | cpu0 %tim cpu1 %tim
> >> > -+--
> >> >e1000g#0 | 1 0,0 0 0,0
> >> > ehci#0 | 0 0,0 4 0,0
> >> > ehci#1 | 3 0,0 0 0,0
> >> > hci1394#0 | 0 0,0 2 0,0
> >> > i8042#1 | 0 0,0 4 0,0
> >> > i915#1 | 0 0,0 2 0,0
> >> > pci-ide#0 |15 0,1 0 0,0
> >> > uhci#0 | 0 0,0 2 0,0
> >> > uhci#1 | 0 0,0 0 0,0
> >> > uhci#2 | 3 0,0 0 0,0
> >> > uhci#3 | 0 0,0 2 0,0
> >> > uhci#4 | 0 0,0 4 0,0
> >> >
> >> > device | cpu0 %tim cpu1 %tim
> >> > -+--
> >> >e1000g#0 | 1 0,0 0 0,0
> >> > ehci#0 | 0 0,0 3 0,0
> >> > ehci#1 | 3 0,0 0 0,0
> >> > hci1394#0 | 0 0,0 1 0,0
> >> > i8042#1 | 0 0,0 6 0,0
> >> > i915#1 | 0 0,0 1 0,0
> >> > pci-ide#0 | 3 0,0 0 0,0
> >> > uhci#0 | 0 0,0 1 0,0
> >> > uhci#1 | 0 0,0 0 0,0
> >> > uhci#2 | 3 0,0 0 0,0
> >> > uhci#3 | 0 0,0 1 0,0
> >> > uhci#4 | 0 0,0 3 0,0
> >> >
> >> > gernot@tintenfass:~# vmstat 5 10
> >> > kthr memorypagedisk faults
> >> > cpu
> >> > r b w swap free re mf pi po fr de sr cd s0 s1 s2 in sy cs
> >>us
> >> > sy id
> >> > 0 0 0 4243840 1145720 1 6 0 0 0 0 2 0 1 1 1 9767 121
> >>37073 0
> >> > 54 46
> >> > 0 0 0 4157824 1059796 4 11 0 0 0 0 0 0 0 0 0 9752 119
> >>37132 0
> >> > 54 46
> >> > 0 0 0 4157736 1059752 0 0 0 0 0 0 0 0 0 0 0 9769 113
> >>37194 0
> >> > 54 46
> >> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9682 104
> >>36941 0
> >> > 54 46
> >> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9769 105
> >>37208 0
> >> > 54 46
> >> > 0 0 0 4157728 1059772 0 1 0 0 0 0 0 0 0 0 0 9741 159
> >>37104 0
> >> > 54 46
> >> > 0 0 0 4157728 1059772 0 0 0 0 0 0 0 0 0 0 0 9695 127
> >>36931 0
> >> > 54 46
> >> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9762 105
> >>37188 0
> >> > 54 46
> >> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9723 102
> >>37058 0
> >> > 54 46
> >> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9774 105
> >>37263 0
> >> > 54 46
> >> >
> >> > Mike
> >> >
> >> >
> >> > On Thu, 2011-10-20 at 11:02 -0700, Rennie Allen wrote:
> >> >
> >> >> Sched is the scheduler itself. How long did you let this run? If
> >>only
> >> >> for a couple of seconds, then that number is high, but not
> >>ridiculous for
> >> >> a loaded system, so I think that this output rules out a high context
> >> >> switch rate.
> >> >>
> >> >> Try this command to see if some process is making an excessive
> >>number of
> >> >> syscalls:
> >> >>
> >> >> dtrace -n 'syscall:::entry { @[execname]=count()}'
> >> >>
> >> >> If not, then I'd try looking at interrupts...
> >> >>
> >> >>
> >> >> On 10/20/11 10:52 AM, "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 s
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
On Thu, Oct 20, 2011 at 20:55, Michael Stapleton wrote: > You might be right. > > But 45% of what? > > Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec) > > Count indv cuml rcnt nsec Hottest CPU+PIL > Caller > --- > 2649 45% 45% 0.00 1070 cpu[1] > i86_mwait > 358 6% 51% 0.00 963 cpu[0] > AcpiDebugPrint > 333 6% 57% 0.00 960 cpu[0] > AcpiUtTrackStackPtr > > 2649 times in 30 seconds totaling 1070 ns does not seem like much to me. > > My idle laptop shows: > > Count indv cuml rcnt nsec Hottest CPU+PIL > Caller > --- > 5441 93% 93% 0.00 3132 cpu[0] > i86_mwait hmm ... good point. Gernot? ;-) -- Michael Schuster http://recursiveramblings.wordpress.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
You might be right. But 45% of what? Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec) Count indv cuml rcnt nsec Hottest CPU+PIL Caller --- 2649 45% 45% 0.00 1070 cpu[1] i86_mwait 358 6% 51% 0.00 963 cpu[0] AcpiDebugPrint 333 6% 57% 0.00 960 cpu[0] AcpiUtTrackStackPtr 2649 times in 30 seconds totaling 1070 ns does not seem like much to me. My idle laptop shows: Count indv cuml rcnt nsec Hottest CPU+PIL Caller --- 5441 93% 93% 0.00 3132 cpu[0] i86_mwait Mike On Thu, 2011-10-20 at 20:37 +0200, Michael Schuster wrote: > On Thu, Oct 20, 2011 at 20:33, Michael Stapleton > wrote: > > Don't know. I don't like to trouble shoot by guess if possible. I rather > > follow the evidence to capture the culprit. Use what we know to discover > > what we do not know. > > if you're answering my question: I'm not guessing that much: I looked > at lockstat output, and right there at the top we see i86_mwait > consuming 45%(!) ... so, popped that into google, the link I quote is > the first to appear, and the description matches well enough that I'd > give it a try. > > Since Gernot is seeing the issue, maybe he wants to pitch in here? > > regards > Michael > > On Thu, 2011-10-20 at 20:25 +0200, Michael Schuster wrote: > > > >> Hi, > >> > >> just found this: > >> http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html > >> > >> does it help? ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
I'd like to see a run of the script I sent earlier. I don't trust
intrstat (not for any particular reason, other than that I have never used
it)...
On 10/20/11 11:33 AM, "Michael Stapleton"
wrote:
>Don't know. I don't like to trouble shoot by guess if possible. I rather
>follow the evidence to capture the culprit. Use what we know to discover
>what we do not know.
>
>We know CS rate in vmstat is high, we know Sys time is high, we know
>syscall rate is low, we know it is not a user process therefor it is
>kernel. Likely a driver.
>
>So what kernel code is running the most?
>
>What's causing that code to run?
>
>Does that code belong to a driver?
>
>
>Mike
>
>
>
>On Thu, 2011-10-20 at 20:25 +0200, Michael Schuster wrote:
>
>> Hi,
>>
>> just found this:
>> http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
>>
>> does it help?
>>
>> On Thu, Oct 20, 2011 at 20:23, Michael Stapleton
>> wrote:
>> > My understanding is that it is not supposed to be a loaded system. We
>> > want to know what the load is.
>> >
>> >
>> > gernot@tintenfass:~# intrstat 30
>> >
>> > device | cpu0 %tim cpu1 %tim
>> > -+--
>> >e1000g#0 | 1 0,0 0 0,0
>> > ehci#0 | 0 0,0 4 0,0
>> > ehci#1 | 3 0,0 0 0,0
>> > hci1394#0 | 0 0,0 2 0,0
>> > i8042#1 | 0 0,0 4 0,0
>> > i915#1 | 0 0,0 2 0,0
>> > pci-ide#0 |15 0,1 0 0,0
>> > uhci#0 | 0 0,0 2 0,0
>> > uhci#1 | 0 0,0 0 0,0
>> > uhci#2 | 3 0,0 0 0,0
>> > uhci#3 | 0 0,0 2 0,0
>> > uhci#4 | 0 0,0 4 0,0
>> >
>> > device | cpu0 %tim cpu1 %tim
>> > -+--
>> >e1000g#0 | 1 0,0 0 0,0
>> > ehci#0 | 0 0,0 3 0,0
>> > ehci#1 | 3 0,0 0 0,0
>> > hci1394#0 | 0 0,0 1 0,0
>> > i8042#1 | 0 0,0 6 0,0
>> > i915#1 | 0 0,0 1 0,0
>> > pci-ide#0 | 3 0,0 0 0,0
>> > uhci#0 | 0 0,0 1 0,0
>> > uhci#1 | 0 0,0 0 0,0
>> > uhci#2 | 3 0,0 0 0,0
>> > uhci#3 | 0 0,0 1 0,0
>> > uhci#4 | 0 0,0 3 0,0
>> >
>> > gernot@tintenfass:~# vmstat 5 10
>> > kthr memorypagedisk faults
>> > cpu
>> > r b w swap free re mf pi po fr de sr cd s0 s1 s2 in sy cs
>>us
>> > sy id
>> > 0 0 0 4243840 1145720 1 6 0 0 0 0 2 0 1 1 1 9767 121
>>37073 0
>> > 54 46
>> > 0 0 0 4157824 1059796 4 11 0 0 0 0 0 0 0 0 0 9752 119
>>37132 0
>> > 54 46
>> > 0 0 0 4157736 1059752 0 0 0 0 0 0 0 0 0 0 0 9769 113
>>37194 0
>> > 54 46
>> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9682 104
>>36941 0
>> > 54 46
>> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9769 105
>>37208 0
>> > 54 46
>> > 0 0 0 4157728 1059772 0 1 0 0 0 0 0 0 0 0 0 9741 159
>>37104 0
>> > 54 46
>> > 0 0 0 4157728 1059772 0 0 0 0 0 0 0 0 0 0 0 9695 127
>>36931 0
>> > 54 46
>> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9762 105
>>37188 0
>> > 54 46
>> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9723 102
>>37058 0
>> > 54 46
>> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9774 105
>>37263 0
>> > 54 46
>> >
>> > Mike
>> >
>> >
>> > On Thu, 2011-10-20 at 11:02 -0700, Rennie Allen wrote:
>> >
>> >> Sched is the scheduler itself. How long did you let this run? If
>>only
>> >> for a couple of seconds, then that number is high, but not
>>ridiculous for
>> >> a loaded system, so I think that this output rules out a high context
>> >> switch rate.
>> >>
>> >> Try this command to see if some process is making an excessive
>>number of
>> >> syscalls:
>> >>
>> >> dtrace -n 'syscall:::entry { @[execname]=count()}'
>> >>
>> >> If not, then I'd try looking at interrupts...
>> >>
>> >>
>> >> On 10/20/11 10:52 AM, "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@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
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
On Thu, Oct 20, 2011 at 20:33, Michael Stapleton wrote: > Don't know. I don't like to trouble shoot by guess if possible. I rather > follow the evidence to capture the culprit. Use what we know to discover > what we do not know. if you're answering my question: I'm not guessing that much: I looked at lockstat output, and right there at the top we see i86_mwait consuming 45%(!) ... so, popped that into google, the link I quote is the first to appear, and the description matches well enough that I'd give it a try. Since Gernot is seeing the issue, maybe he wants to pitch in here? regards Michael > On Thu, 2011-10-20 at 20:25 +0200, Michael Schuster wrote: > >> Hi, >> >> just found this: >> http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html >> >> does it help? -- Michael Schuster http://recursiveramblings.wordpress.com/ ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Don't know. I don't like to trouble shoot by guess if possible. I rather
follow the evidence to capture the culprit. Use what we know to discover
what we do not know.
We know CS rate in vmstat is high, we know Sys time is high, we know
syscall rate is low, we know it is not a user process therefor it is
kernel. Likely a driver.
So what kernel code is running the most?
What's causing that code to run?
Does that code belong to a driver?
Mike
On Thu, 2011-10-20 at 20:25 +0200, Michael Schuster wrote:
> Hi,
>
> just found this:
> http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
>
> does it help?
>
> On Thu, Oct 20, 2011 at 20:23, Michael Stapleton
> wrote:
> > My understanding is that it is not supposed to be a loaded system. We
> > want to know what the load is.
> >
> >
> > gernot@tintenfass:~# intrstat 30
> >
> > device | cpu0 %tim cpu1 %tim
> > -+--
> >e1000g#0 | 1 0,0 0 0,0
> > ehci#0 | 0 0,0 4 0,0
> > ehci#1 | 3 0,0 0 0,0
> > hci1394#0 | 0 0,0 2 0,0
> > i8042#1 | 0 0,0 4 0,0
> > i915#1 | 0 0,0 2 0,0
> > pci-ide#0 |15 0,1 0 0,0
> > uhci#0 | 0 0,0 2 0,0
> > uhci#1 | 0 0,0 0 0,0
> > uhci#2 | 3 0,0 0 0,0
> > uhci#3 | 0 0,0 2 0,0
> > uhci#4 | 0 0,0 4 0,0
> >
> > device | cpu0 %tim cpu1 %tim
> > -+--
> >e1000g#0 | 1 0,0 0 0,0
> > ehci#0 | 0 0,0 3 0,0
> > ehci#1 | 3 0,0 0 0,0
> > hci1394#0 | 0 0,0 1 0,0
> > i8042#1 | 0 0,0 6 0,0
> > i915#1 | 0 0,0 1 0,0
> > pci-ide#0 | 3 0,0 0 0,0
> > uhci#0 | 0 0,0 1 0,0
> > uhci#1 | 0 0,0 0 0,0
> > uhci#2 | 3 0,0 0 0,0
> > uhci#3 | 0 0,0 1 0,0
> > uhci#4 | 0 0,0 3 0,0
> >
> > gernot@tintenfass:~# vmstat 5 10
> > kthr memorypagedisk faults
> > cpu
> > r b w swap free re mf pi po fr de sr cd s0 s1 s2 in sy cs us
> > sy id
> > 0 0 0 4243840 1145720 1 6 0 0 0 0 2 0 1 1 1 9767 121 37073 0
> > 54 46
> > 0 0 0 4157824 1059796 4 11 0 0 0 0 0 0 0 0 0 9752 119 37132 0
> > 54 46
> > 0 0 0 4157736 1059752 0 0 0 0 0 0 0 0 0 0 0 9769 113 37194 0
> > 54 46
> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9682 104 36941 0
> > 54 46
> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9769 105 37208 0
> > 54 46
> > 0 0 0 4157728 1059772 0 1 0 0 0 0 0 0 0 0 0 9741 159 37104 0
> > 54 46
> > 0 0 0 4157728 1059772 0 0 0 0 0 0 0 0 0 0 0 9695 127 36931 0
> > 54 46
> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9762 105 37188 0
> > 54 46
> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9723 102 37058 0
> > 54 46
> > 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9774 105 37263 0
> > 54 46
> >
> > Mike
> >
> >
> > On Thu, 2011-10-20 at 11:02 -0700, Rennie Allen wrote:
> >
> >> Sched is the scheduler itself. How long did you let this run? If only
> >> for a couple of seconds, then that number is high, but not ridiculous for
> >> a loaded system, so I think that this output rules out a high context
> >> switch rate.
> >>
> >> Try this command to see if some process is making an excessive number of
> >> syscalls:
> >>
> >> dtrace -n 'syscall:::entry { @[execname]=count()}'
> >>
> >> If not, then I'd try looking at interrupts...
> >>
> >>
> >> On 10/20/11 10:52 AM, "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@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
> >> > idmapd2
> >> > inetd 2
> >> > miniserv.pl 2
> >> > netcfgd
Re: [OpenIndiana-discuss] CIFS Alias/Multiple connections
On Thu, Oct 20, 2011 at 12:48 PM, Jonathan Leafty wrote: > No they're just set up in DNS. After b134 (any flavor, OpenSolaris, Solaris > 11 Express) it won't accept CIFS connections to DNS aliases. > > Windows 2008 is the same way, but you can flip a registry setting to let SMB > Connections come in on DNS Aliases even if its not set as a SPN alias (the > more proper way). > > Which brings me to another problem. I can't authenticate against the actual > AD SPN/Hostname, I get access denied. But I believe I've seen a bug report > about it. I can go to \\hostname, but not \\hostname.fqdn if I had a DNS > alias as a SPN alias, it will do the same. I haven't packet sniffed yet, as > its not a huge issue and since there was a bug report. Yes, here's the issue for that: https://www.illumos.org/issues/1087 Unable to connect to the CIFS server using \\servername.fqdn We have someone working on it. Perhaps your alias problem is related. Do you have network captures for the failure? Is it the session setup that fails? Tree connect? Thanks, Gordon ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Hi,
just found this:
http://download.oracle.com/docs/cd/E19253-01/820-5245/ghgoc/index.html
does it help?
On Thu, Oct 20, 2011 at 20:23, Michael Stapleton
wrote:
> My understanding is that it is not supposed to be a loaded system. We
> want to know what the load is.
>
>
> gernot@tintenfass:~# intrstat 30
>
> device | cpu0 %tim cpu1 %tim
> -+--
> e1000g#0 | 1 0,0 0 0,0
> ehci#0 | 0 0,0 4 0,0
> ehci#1 | 3 0,0 0 0,0
> hci1394#0 | 0 0,0 2 0,0
> i8042#1 | 0 0,0 4 0,0
> i915#1 | 0 0,0 2 0,0
> pci-ide#0 | 15 0,1 0 0,0
> uhci#0 | 0 0,0 2 0,0
> uhci#1 | 0 0,0 0 0,0
> uhci#2 | 3 0,0 0 0,0
> uhci#3 | 0 0,0 2 0,0
> uhci#4 | 0 0,0 4 0,0
>
> device | cpu0 %tim cpu1 %tim
> -+--
> e1000g#0 | 1 0,0 0 0,0
> ehci#0 | 0 0,0 3 0,0
> ehci#1 | 3 0,0 0 0,0
> hci1394#0 | 0 0,0 1 0,0
> i8042#1 | 0 0,0 6 0,0
> i915#1 | 0 0,0 1 0,0
> pci-ide#0 | 3 0,0 0 0,0
> uhci#0 | 0 0,0 1 0,0
> uhci#1 | 0 0,0 0 0,0
> uhci#2 | 3 0,0 0 0,0
> uhci#3 | 0 0,0 1 0,0
> uhci#4 | 0 0,0 3 0,0
>
> gernot@tintenfass:~# vmstat 5 10
> kthr memory page disk faults
> cpu
> r b w swap free re mf pi po fr de sr cd s0 s1 s2 in sy cs us
> sy id
> 0 0 0 4243840 1145720 1 6 0 0 0 0 2 0 1 1 1 9767 121 37073 0
> 54 46
> 0 0 0 4157824 1059796 4 11 0 0 0 0 0 0 0 0 0 9752 119 37132 0
> 54 46
> 0 0 0 4157736 1059752 0 0 0 0 0 0 0 0 0 0 0 9769 113 37194 0
> 54 46
> 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9682 104 36941 0
> 54 46
> 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9769 105 37208 0
> 54 46
> 0 0 0 4157728 1059772 0 1 0 0 0 0 0 0 0 0 0 9741 159 37104 0
> 54 46
> 0 0 0 4157728 1059772 0 0 0 0 0 0 0 0 0 0 0 9695 127 36931 0
> 54 46
> 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9762 105 37188 0
> 54 46
> 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9723 102 37058 0
> 54 46
> 0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9774 105 37263 0
> 54 46
>
> Mike
>
>
> On Thu, 2011-10-20 at 11:02 -0700, Rennie Allen wrote:
>
>> Sched is the scheduler itself. How long did you let this run? If only
>> for a couple of seconds, then that number is high, but not ridiculous for
>> a loaded system, so I think that this output rules out a high context
>> switch rate.
>>
>> Try this command to see if some process is making an excessive number of
>> syscalls:
>>
>> dtrace -n 'syscall:::entry { @[execname]=count()}'
>>
>> If not, then I'd try looking at interrupts...
>>
>>
>> On 10/20/11 10:52 AM, "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@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
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
My understanding is that it is not supposed to be a loaded system. We
want to know what the load is.
gernot@tintenfass:~# intrstat 30
device | cpu0 %tim cpu1 %tim
-+--
e1000g#0 | 1 0,0 0 0,0
ehci#0 | 0 0,0 4 0,0
ehci#1 | 3 0,0 0 0,0
hci1394#0 | 0 0,0 2 0,0
i8042#1 | 0 0,0 4 0,0
i915#1 | 0 0,0 2 0,0
pci-ide#0 |15 0,1 0 0,0
uhci#0 | 0 0,0 2 0,0
uhci#1 | 0 0,0 0 0,0
uhci#2 | 3 0,0 0 0,0
uhci#3 | 0 0,0 2 0,0
uhci#4 | 0 0,0 4 0,0
device | cpu0 %tim cpu1 %tim
-+--
e1000g#0 | 1 0,0 0 0,0
ehci#0 | 0 0,0 3 0,0
ehci#1 | 3 0,0 0 0,0
hci1394#0 | 0 0,0 1 0,0
i8042#1 | 0 0,0 6 0,0
i915#1 | 0 0,0 1 0,0
pci-ide#0 | 3 0,0 0 0,0
uhci#0 | 0 0,0 1 0,0
uhci#1 | 0 0,0 0 0,0
uhci#2 | 3 0,0 0 0,0
uhci#3 | 0 0,0 1 0,0
uhci#4 | 0 0,0 3 0,0
gernot@tintenfass:~# vmstat 5 10
kthr memorypagedisk faults
cpu
r b w swap free re mf pi po fr de sr cd s0 s1 s2 in sy cs us
sy id
0 0 0 4243840 1145720 1 6 0 0 0 0 2 0 1 1 1 9767 121 37073 0
54 46
0 0 0 4157824 1059796 4 11 0 0 0 0 0 0 0 0 0 9752 119 37132 0
54 46
0 0 0 4157736 1059752 0 0 0 0 0 0 0 0 0 0 0 9769 113 37194 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9682 104 36941 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9769 105 37208 0
54 46
0 0 0 4157728 1059772 0 1 0 0 0 0 0 0 0 0 0 9741 159 37104 0
54 46
0 0 0 4157728 1059772 0 0 0 0 0 0 0 0 0 0 0 9695 127 36931 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9762 105 37188 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9723 102 37058 0
54 46
0 0 0 4157744 1059788 0 0 0 0 0 0 0 0 0 0 0 9774 105 37263 0
54 46
Mike
On Thu, 2011-10-20 at 11:02 -0700, Rennie Allen wrote:
> Sched is the scheduler itself. How long did you let this run? If only
> for a couple of seconds, then that number is high, but not ridiculous for
> a loaded system, so I think that this output rules out a high context
> switch rate.
>
> Try this command to see if some process is making an excessive number of
> syscalls:
>
> dtrace -n 'syscall:::entry { @[execname]=count()}'
>
> If not, then I'd try looking at interrupts...
>
>
> On 10/20/11 10:52 AM, "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@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
> > idmapd2
> > inetd 2
> > miniserv.pl 2
> > netcfgd 2
> > nscd 2
> > ospm-applet 2
> > ssh-agent 2
> > sshd 2
> > svc.startd2
> > intrd 3
> > afpd 4
> > mdnsd 4
> > gnome-power-mana 5
> > clock-applet 7
> > sendmail 7
> > xscreensaver 7
> > fmd 9
> > fsflush
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Try the following script, which will identify any drivers with high
interrupt load
-
#!/usr/sbin/dtrace -s
sdt:::interrupt-start { self->ts = vtimestamp; }
sdt:::interrupt-complete
/self->ts && arg0 != 0/
{
this->devi = (struct dev_info *)arg0;
self->name = this->devi != 0 ?
stringof(`devnamesp[this->devi->devi_major].dn_name) : "?";
this->inst = this->devi != 0 ? this->devi->devi_instance : 0;
@num[self->name, this->inst] = sum(vtimestamp - self->ts);
self->name = 0;
}
sdt:::interrupt-complete { self->ts = 0; }
dtrace:::END
{
printf("%11s%16s\n", "DEVICE", "TIME (ns)");
printa("%10s%-3d %@16d\n", @num);
}
-
On 10/20/11 11:07 AM, "Michael Stapleton"
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@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
>>idmapd2
>>inetd 2
>>miniserv.pl 2
>>netcfgd 2
>>nscd 2
>>ospm-applet 2
>>ssh-agent 2
>>sshd 2
>>svc.startd2
>>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_applet225
>>smbd 39
>>nwam-manager 60
>>svc.configd 79
>>Xorg100
>>sched394078
>>
>> gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
>> dtrace: description 'sched:::off-cpu ' matched 3 probes
>> ^C
>>
>>automountd1
>>ipmgmtd 1
>>idmapd2
>>in.routed 2
>>init 2
>>miniserv.pl 2
>>netcfgd 2
>>ssh-agent 2
>>sshd
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Gernot,
is there anything suspicious in /var/adm/messages?
Michael
On Thu, Oct 20, 2011 at 20:07, Michael Stapleton
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@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@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
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Wow, that was fast :) Just caught me with the morning coffee email review. Well, I just had a nice dinner :) However, the NIC integrated on the Intel DG965WHMKR mainbord is an Intel 82566DC according to the device driver utility, the reported driver e1000g. Isn't the bge driver for Broadcom NICs? And like I said, I didn't even scan the logs. Just quick idea off top of my head based on similar behavior. Could well be entirely different underlying cause. Yes, the bge is broadcom but I think there have been issues with other nics. Oh, ic :) And what do you mean by "the other nvidia based interface"? This mainboard has only this one integrated network interface mentioned above, no pieces of nvidia hardware anywhere, as far as I can see... I didn't mean to imply that I had the same mainboard you reported. I have a few different nics lying around so for me this was easy test: bge -> high cpu load under 'idle'; nvidia -> goes away. Well, you certainly have a point here. Nevertheless it could be worth to try a different network driver. However, as I mentioned in my previous post, my know-how concerning unix is very limited. Where can I find an alternative driver for the Intel 82566DC interface and how do I install it? Is this laptop of desktop? If latter, can you just try a different card? If so, OI should automatically detect and load appropriate driver. Desktop. Good idea. I have this prehistoric PC here at my place, I think I can try and put it's NIC into my OI box. But that's for tomorrow :) Anyway, thanks for your quick response! :) Np. Sorry is wasn't much help. But I see others are putting you on diagnostic dtrace track so I'll bow out now. Good luck :) Thx :) I'm curious what they will get from the results I posted. Have a nice day! :) Regards, Gernot Wolf ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
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@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
>idmapd2
>inetd 2
>miniserv.pl 2
>netcfgd 2
>nscd 2
>ospm-applet 2
>ssh-agent 2
>sshd 2
>svc.startd2
>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_applet225
>smbd 39
>nwam-manager 60
>svc.configd 79
>Xorg100
>sched394078
>
> gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
> dtrace: description 'sched:::off-cpu ' matched 3 probes
> ^C
>
>automountd1
>ipmgmtd 1
>idmapd2
>in.routed 2
>init 2
>miniserv.pl 2
>netcfgd 2
>ssh-agent 2
>sshd 2
>svc.startd2
>fmd 3
>hald 3
>inetd 3
>intrd 3
>hald-addon-acpi 4
>nscd 4
>gnome-power-mana 5
>sendmail 5
>mdnsd 6
>devfsadm 8
>xscreens
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Sched is the scheduler itself. How long did you let this run? If only
for a couple of seconds, then that number is high, but not ridiculous for
a loaded system, so I think that this output rules out a high context
switch rate.
Try this command to see if some process is making an excessive number of
syscalls:
dtrace -n 'syscall:::entry { @[execname]=count()}'
If not, then I'd try looking at interrupts...
On 10/20/11 10:52 AM, "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@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
> idmapd2
> inetd 2
> miniserv.pl 2
> netcfgd 2
> nscd 2
> ospm-applet 2
> ssh-agent 2
> sshd 2
> svc.startd2
> 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_applet225
> smbd 39
> nwam-manager 60
> svc.configd 79
> Xorg100
> sched394078
>
>gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
>dtrace: description 'sched:::off-cpu ' matched 3 probes
>^C
>
> automountd1
> ipmgmtd 1
> idmapd2
> in.routed 2
> init 2
> miniserv.pl 2
> netcfgd 2
> ssh-agent 2
> sshd 2
> svc.startd2
> 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
>
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Your lockstat output fingers Acpi debug tracing functions. I wonder why these are running in the first place. Steve - Original Message - Hello all, I have a machine here at my home running OpenIndiana oi_151a, which serves as a NAS on my home network. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
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@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
idmapd2
inetd 2
miniserv.pl 2
netcfgd 2
nscd 2
ospm-applet 2
ssh-agent 2
sshd 2
svc.startd2
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_applet225
smbd 39
nwam-manager 60
svc.configd 79
Xorg100
sched394078
gernot@tintenfass:~# dtrace -n 'sched:::off-cpu { @[execname]=count()}'
dtrace: description 'sched:::off-cpu ' matched 3 probes
^C
automountd1
ipmgmtd 1
idmapd2
in.routed 2
init 2
miniserv.pl 2
netcfgd 2
ssh-agent 2
sshd 2
svc.startd2
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_applet221
isapython2.6 22
dtrace 24
gnome-terminal 24
smbd 39
nwam-manager
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Sure do :-)
People tend to think only about ZFS and maybe Zones. They don't
understand dtrace and resource management.
Solaris is much more than ZFS, but you really have to know what you are
doing to appreciate it.
The true strength of Solaris is server side in the hands of
professionals.
There has been a bit of back and forth about Linux and OpenIndiana
lately, personaly I think we should focus on our strengths.
Mike
On Thu, 2011-10-20 at 10:27 -0700, Rennie Allen wrote:
> Dontchya just love dtrace?
>
>
> On 10/20/11 10:22 AM, "Michael Stapleton"
> wrote:
>
> >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@openindiana.org
> >> http://openindiana.org/mailman/listinfo/openindiana-discuss
> >
> >
> >___
> >OpenIndiana-discuss mailing list
> >OpenIndiana-discuss@openindiana.org
> >http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>
>
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
On Thu, 2011-10-20 at 19:34 +0200, Gernot Wolf wrote: > Wow, that was fast :) Just caught me with the morning coffee email review. > However, the NIC integrated on the Intel DG965WHMKR mainbord is an Intel > 82566DC according to the device driver utility, the reported driver > e1000g. Isn't the bge driver for Broadcom NICs? And like I said, I didn't even scan the logs. Just quick idea off top of my head based on similar behavior. Could well be entirely different underlying cause. Yes, the bge is broadcom but I think there have been issues with other nics. > And what do you mean by "the other nvidia based interface"? This > mainboard has only this one integrated network interface mentioned > above, no pieces of nvidia hardware anywhere, as far as I can see... I didn't mean to imply that I had the same mainboard you reported. I have a few different nics lying around so for me this was easy test: bge -> high cpu load under 'idle'; nvidia -> goes away. > Nevertheless it could be worth to try a different network driver. > However, as I mentioned in my previous post, my know-how concerning unix > is very limited. Where can I find an alternative driver for the Intel > 82566DC interface and how do I install it? Is this laptop of desktop? If latter, can you just try a different card? If so, OI should automatically detect and load appropriate driver. > Anyway, thanks for your quick response! :) Np. Sorry is wasn't much help. But I see others are putting you on diagnostic dtrace track so I'll bow out now. Good luck :) -- Regards-- Ken Gunderson ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Wow, that was fast :) However, the NIC integrated on the Intel DG965WHMKR mainbord is an Intel 82566DC according to the device driver utility, the reported driver e1000g. Isn't the bge driver for Broadcom NICs? And what do you mean by "the other nvidia based interface"? This mainboard has only this one integrated network interface mentioned above, no pieces of nvidia hardware anywhere, as far as I can see... Nevertheless it could be worth to try a different network driver. However, as I mentioned in my previous post, my know-how concerning unix is very limited. Where can I find an alternative driver for the Intel 82566DC interface and how do I install it? Anyway, thanks for your quick response! :) Regards, Gernot Wolf Am 20.10.11 18:52, schrieb Ken Gunderson: One. But I haven't even made cursory scan of your logs. Nor do I know if it is problem any longer but I used to see similar with bge driver. Worked great on OS 2009.06 but subsequent stuff horked it up somehow. My solution was to use the other nvidia based interface. I think there is/was a bug file on Illumos Redmine? Others will surely know more but quick test you can do is to try a different network driver and see if the problem goes away. hth-- Ken ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
Dontchya just love dtrace?
On 10/20/11 10:22 AM, "Michael Stapleton"
wrote:
>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@openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>
>
>___
>OpenIndiana-discuss mailing list
>OpenIndiana-discuss@openindiana.org
>http://openindiana.org/mailman/listinfo/openindiana-discuss
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
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@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS Alias/Multiple connections
I saw a comment it was fixed in Opensolaris snv_161 (I think) but you can't get that. It seems to work for me in OI 148, but I haven't tested it extensively yet, but opening 2 windows on two different aliases work. John -Original Message- From: Jonathan Leafty [mailto:jleafty+openindianadisc...@gmail.com] Sent: 20 October 2011 17:48 To: Discussion list for OpenIndiana Subject: Re: [OpenIndiana-discuss] CIFS Alias/Multiple connections No they're just set up in DNS. After b134 (any flavor, OpenSolaris, Solaris 11 Express) it won't accept CIFS connections to DNS aliases. Windows 2008 is the same way, but you can flip a registry setting to let SMB Connections come in on DNS Aliases even if its not set as a SPN alias (the more proper way). Which brings me to another problem. I can't authenticate against the actual AD SPN/Hostname, I get access denied. But I believe I've seen a bug report about it. I can go to \\hostname, but not \\hostname.fqdn if I had a DNS alias as a SPN alias, it will do the same. I haven't packet sniffed yet, as its not a huge issue and since there was a bug report. PS I've deleted and re-added the machine back to the domain too. On Wed, Oct 19, 2011 at 9:31 PM, Gordon Ross wrote: > How did you setup the "aliases"? Are these virtual NICs like bge0:1 ? > > On Wed, Oct 19, 2011 at 5:38 PM, Jonathan Leafty > wrote: > > Back in OpenSolaris b134 and previous, I was able to make multiple > > connections from my Windows 7 machines to my server using aliases. It > seems > > like I can no longer do it, like say I have alias1 , if I hit alias2 the > > other connection fails. > > > > My main issue are issues because my backup software uses other > credentials > > (since I don't want my credentials having delete rights) and seemingly > > related connectivity problems. > > > > I did a search, I may be missing it, but is this on the radar to be > fixed? > > > > Solaris 11 Express has the same issue > > ___ > > OpenIndiana-discuss mailing list > > OpenIndiana-discuss@openindiana.org > > http://openindiana.org/mailman/listinfo/openindiana-discuss > > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss ___ The contents of this e-mail and any attachment(s) are strictly confidential and are solely for the person(s) at the e-mail address(es) above. If you are not an addressee, you may not disclose, distribute, copy or use this e-mail, and we request that you send an e-mail to ad...@stirling-dynamics.com and delete this e-mail. Stirling Dynamics Ltd. accepts no legal liability for the contents of this e-mail including any errors, interception or interference, as internet communications are not secure. Any views or opinions presented are solely those of the author and do not necessarily represent those of Stirling Dynamics Ltd. Registered In England No. 2092114 Registered Office: 26 Regent Street, Clifton, Bristol. BS8 4HG VAT no. GB 464 6551 29 ___ This e-mail has been scanned for all viruses MessageLabs. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problem with high cpu load (oi_151a)
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...? One. But I haven't even made cursory scan of your logs. Nor do I know if it is problem any longer but I used to see similar with bge driver. Worked great on OS 2009.06 but subsequent stuff horked it up somehow. My solution was to use the other nvidia based interface. I think there is/was a bug file on Illumos Redmine? Others will surely know more but quick test you can do is to try a different network driver and see if the problem goes away. hth-- Ken -- Regards-- Ken Gunderson ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS Alias/Multiple connections
Sorry I meant it won't accept DNS aliases at the same time. On Thu, Oct 20, 2011 at 9:48 AM, Jonathan Leafty < jleafty+openindianadisc...@gmail.com> wrote: > No they're just set up in DNS. After b134 (any flavor, OpenSolaris, > Solaris 11 Express) it won't accept CIFS connections to DNS aliases. > > Windows 2008 is the same way, but you can flip a registry setting to let > SMB Connections come in on DNS Aliases even if its not set as a SPN alias > (the more proper way). > > Which brings me to another problem. I can't authenticate against the > actual AD SPN/Hostname, I get access denied. But I believe I've seen a bug > report about it. I can go to \\hostname, but not \\hostname.fqdn if I had > a DNS alias as a SPN alias, it will do the same. I haven't packet sniffed > yet, as its not a huge issue and since there was a bug report. > > PS I've deleted and re-added the machine back to the domain too. > > > On Wed, Oct 19, 2011 at 9:31 PM, Gordon Ross wrote: > >> How did you setup the "aliases"? Are these virtual NICs like bge0:1 ? >> >> On Wed, Oct 19, 2011 at 5:38 PM, Jonathan Leafty >> wrote: >> > Back in OpenSolaris b134 and previous, I was able to make multiple >> > connections from my Windows 7 machines to my server using aliases. It >> seems >> > like I can no longer do it, like say I have alias1 , if I hit alias2 the >> > other connection fails. >> > >> > My main issue are issues because my backup software uses other >> credentials >> > (since I don't want my credentials having delete rights) and seemingly >> > related connectivity problems. >> > >> > I did a search, I may be missing it, but is this on the radar to be >> fixed? >> > >> > Solaris 11 Express has the same issue >> > ___ >> > OpenIndiana-discuss mailing list >> > OpenIndiana-discuss@openindiana.org >> > http://openindiana.org/mailman/listinfo/openindiana-discuss >> > >> >> ___ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> > > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] CIFS Alias/Multiple connections
No they're just set up in DNS. After b134 (any flavor, OpenSolaris, Solaris 11 Express) it won't accept CIFS connections to DNS aliases. Windows 2008 is the same way, but you can flip a registry setting to let SMB Connections come in on DNS Aliases even if its not set as a SPN alias (the more proper way). Which brings me to another problem. I can't authenticate against the actual AD SPN/Hostname, I get access denied. But I believe I've seen a bug report about it. I can go to \\hostname, but not \\hostname.fqdn if I had a DNS alias as a SPN alias, it will do the same. I haven't packet sniffed yet, as its not a huge issue and since there was a bug report. PS I've deleted and re-added the machine back to the domain too. On Wed, Oct 19, 2011 at 9:31 PM, Gordon Ross wrote: > How did you setup the "aliases"? Are these virtual NICs like bge0:1 ? > > On Wed, Oct 19, 2011 at 5:38 PM, Jonathan Leafty > wrote: > > Back in OpenSolaris b134 and previous, I was able to make multiple > > connections from my Windows 7 machines to my server using aliases. It > seems > > like I can no longer do it, like say I have alias1 , if I hit alias2 the > > other connection fails. > > > > My main issue are issues because my backup software uses other > credentials > > (since I don't want my credentials having delete rights) and seemingly > > related connectivity problems. > > > > I did a search, I may be missing it, but is this on the radar to be > fixed? > > > > Solaris 11 Express has the same issue > > ___ > > OpenIndiana-discuss mailing list > > OpenIndiana-discuss@openindiana.org > > http://openindiana.org/mailman/listinfo/openindiana-discuss > > > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] Problem with high cpu load (oi_151a)
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 gernot@tintenfass:~# intrstat 30 device | cpu0 %tim cpu1 %tim -+-- e1000g#0 | 1 0,0 0 0,0 ehci#0 | 0 0,0 4 0,0 ehci#1 | 3 0,0 0 0,0 hci1394#0 | 0 0,0 2 0,0 i8042#1 | 0 0,0 4 0,0 i915#1 | 0 0,0 2 0,0 pci-ide#0 |15 0,1 0 0,0 uhci#0 | 0 0,0 2 0,0 uhci#1 | 0 0,0 0 0,0 uhci#2 | 3 0,0 0 0,0 uhci#3 | 0 0,0 2 0,0 uhci#4 | 0 0,0 4 0,0 device | cpu0 %tim cpu1 %tim -+-- e1000g#0 | 1 0,0 0 0,0 ehci#0 | 0 0,0 3 0,0 ehci#1 | 3 0,0 0 0,0 hci1394#0 | 0 0,0 1 0,0 i8042#1 | 0 0,0 6 0,0 i915#1 | 0 0,0 1 0,0 pci-ide#0 | 3 0,0 0 0,0 uhci#0 | 0 0,0 1 0,0 uhci#1 | 0 0,0 0 0,0 uhci#2 | 3 0,0 0 0,0 uhci#3 | 0 0,0 1 0,0 uhci#4 | 0 0,0 3 0,0 gernot@tintenfass:~# iostat 5 10 tty cmdk0 sd0 sd1 sd2cpu tin tout kps tps serv kps tps serv kps tps serv kps tps serv us sy wt id 0 15 4 0 17 28 16 26 16 27 170 54 0 46 0 47 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 0 16 0 000 000 000 000 54 0 46 gernot@tintenfass:~# lockstat -kIW -D 20 sleep 30 Profiling interrupt: 5844 events in 30.123 seconds (194 events/sec) Count indv cuml rcnt nsec Hottest CPU+PILCaller --- 2649 45% 45% 0.00 1070 cpu[1] i86_mwait 358 6% 51% 0.00 963 cpu[0] AcpiDebugPrint 333 6% 57% 0.00 960 cpu[0] AcpiUtTrackStackPtr 228 4% 61% 0.00 972 cpu[0] AcpiExNameSegment 221 4% 65% 0.00 123
Re: [OpenIndiana-discuss] Problems with vboxnet0 interface
On Thu, Oct 20, 2011 at 9:30 AM, Jonathan Adams wrote: > I'm using nwam, so I have the vboxnet0 in /etc/nwam/llp and > /etc/nwam/ncp-User.conf Jonathan, Thanks. Due to your responses, I was able to get it working either way, with ipadm or nwam. The last thing I had to realize was don't try mixing them. Use /etc/nwam/llp to specify vboxnet0's static IP instead of setting it via ipadm. Again, thanks, Ron ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] NFS and aggregation
If you need multiple connections, use multiple IPs and/or host names. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problems with vboxnet0 interface
I'm using nwam, so I have the vboxnet0 in /etc/nwam/llp and /etc/nwam/ncp-User.conf On 20 October 2011 15:10, Ron Parker wrote: > On Wed, Oct 19, 2011 at 4:16 AM, Jonathan Adams wrote: >> did you set 'vboxnet0's IP address to 192.168.56.1/24 after you brought it >> up? >> >> On 18 October 2011 22:12, Ron Parker wrote: >>> ... >>> After a 'ipadm create-if vboxnet0', it shows up in ifconfig's output >>> and I was able to assign it an IP, but it still cannot communicate >>> with the clients. I expected that vboxnet0 would just show up and work >>> as it had under Linux (unless there is some long-forgotten step I took >>> to get it working there). > > Ok, I feel stupid now. Yes I had, but I had forgotten to actually > bring up the interface. > > That said I found an online page about ipadm(1m) being the "new" > ifconfig. So, I recreated everything using it: > > ipadm create-if vboxnet0 > ipadm create-addr -T static -a 192.168.56.1/24 vboxnet0/v4static > > and it works. > > However, I have to manually enable and bring the interface up after > each boot. Is there a way to do this automatically? My > /etc/ipadm/ipadm.conf looks like: > > _ifname=vboxnet0;_family=2; > _ifname=vboxnet0;_family=26; > > _ifname=vboxnet0;_aobjname=vboxnet0/v4static;_ipv4addr=192.168.52.1,;up=yes; > _ifname=vboxnet0;_aobjname=vboxnet0/v4static;prefixlen=24; > > Thanks, > > Ron > > ___ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] Problems with vboxnet0 interface
On Wed, Oct 19, 2011 at 4:16 AM, Jonathan Adams wrote: > did you set 'vboxnet0's IP address to 192.168.56.1/24 after you brought it up? > > On 18 October 2011 22:12, Ron Parker wrote: >> ... >> After a 'ipadm create-if vboxnet0', it shows up in ifconfig's output >> and I was able to assign it an IP, but it still cannot communicate >> with the clients. I expected that vboxnet0 would just show up and work >> as it had under Linux (unless there is some long-forgotten step I took >> to get it working there). Ok, I feel stupid now. Yes I had, but I had forgotten to actually bring up the interface. That said I found an online page about ipadm(1m) being the "new" ifconfig. So, I recreated everything using it: ipadm create-if vboxnet0 ipadm create-addr -T static -a 192.168.56.1/24 vboxnet0/v4static and it works. However, I have to manually enable and bring the interface up after each boot. Is there a way to do this automatically? My /etc/ipadm/ipadm.conf looks like: _ifname=vboxnet0;_family=2; _ifname=vboxnet0;_family=26; _ifname=vboxnet0;_aobjname=vboxnet0/v4static;_ipv4addr=192.168.52.1,;up=yes; _ifname=vboxnet0;_aobjname=vboxnet0/v4static;prefixlen=24; Thanks, Ron ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] NFS and aggregation
On 10/20/11 06:24, Gabriele Bulfon wrote: > Hi, after reading a lot, I understand that LACP aggregation won't let me run > a single > connection on all the available links, but just allocate one per connection. > So, considering this, and considering one NFS client mounting a share through > an aggregated > path, I was wondering if multiple files usage by the client will be performed > through different > connections so different links. Generally, no. You'll get one connection per peer. > If the algorythm is choosing the link through MAC &or IP, then I suspect I > will still be using > one link all the time from the same client... Yep. If the hashing mechanism allows you to use L4 (transport layer port numbers) discrimination, then you'll get the finest grain distribution possible. But if it's a single TCP connection, that'll still be a single flow. Ethernet trunking works great for high levels of aggregation and (with LACP) as a low-level redundancy mechanism. It doesn't magically make things go faster, though. If you want that, then you'll have to buy faster hardware. -- James Carlson 42.703N 71.076W ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] NFS and aggregation
Hi, after reading a lot, I understand that LACP aggregation won't let me run a single connection on all the available links, but just allocate one per connection. So, considering this, and considering one NFS client mounting a share through an aggregated path, I was wondering if multiple files usage by the client will be performed through different connections so different links. If the algorythm is choosing the link through MAC &or IP, then I suspect I will still be using one link all the time from the same client... Gabriele. ___ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
[OpenIndiana-discuss] CIFS: dir -> long delay or Error in dskattr: NT_STATUS_IO_TIMEOUT
Hi, my problem occures on a 151a server with a large filesystem (12 TB) exported via sun-cifs. When doing a simple "dir" from a windows mount or a linux or even local smbclient connection I get sometimes a delay of about 20 seconds or sometimes an NT_STATUS_IO_TIMEOUT or sometimes an instant answer. The problem does not appear with a small filesystem on the same server. If I use the samba-server instead of the sun-cifs-server, there is no such problem. Any hints for me? Martin # Script started on Thu Oct 20 11:50:29 2011 root@sunfs5:/root# uname -a SunOS sunfs5 5.11 oi_151a i86pc i386 i86pc root@sunfs5:/root# pkg info smb Name: service/file-system/smb Summary: SMB Server Description: SMB Server libraries and commands Category: System/File System State: Installed Publisher: openindiana.org Version: 0.5.11 Build Release: 5.11 Branch: 0.151.1 Packaging Date: Mon Sep 12 03:14:17 2011 Size: 4.03 MB FMRI: pkg://openindiana.org/service/file-system/smb@0.5.11,5.11-0.151.1:20110912T031417Z Name: system/file-system/smb Summary: SMB/CIFS File System client support Description: SMB/CIFS File System client support Category: System/File System State: Installed Publisher: openindiana.org Version: 0.5.11 Build Release: 5.11 Branch: 0.151.1 Packaging Date: Mon Sep 12 03:15:08 2011 Size: 1.50 MB FMRI: pkg://openindiana.org/system/file-system/smb@0.5.11,5.11-0.151.1:20110912T031508Z root@sunfs5:/root# pkg info samba Name: service/network/samba Summary: samba - A Windows SMB/CIFS fileserver for UNIX Description: samba - A Windows SMB/CIFS fileserver for UNIX Category: System/File System State: Installed Publisher: openindiana.org Version: 3.5.5 Build Release: 5.11 Branch: 0.151.1 Packaging Date: Mon Sep 12 02:48:56 2011 Size: 166.69 MB FMRI: pkg://openindiana.org/service/network/samba@3.5.5,5.11-0.151.1:20110912T024856Z root@sunfs5:/root# svcs -av | grep smb online - 11:12:29 5147 svc:/network/smb/client:default online - 11:12:30 5149 svc:/network/smb/server:default online - 11:12:30 - svc:/network/shares/group:smb root@sunfs5:/root# while sleep 1; do date; time smbclient //sunfs5/home -Dnp2/t -Unp2% -c dir; done Thu Oct 20 11:51:39 CEST 2011 Domain=[PUBLIC] OS=[Windows 2000] Server=[Windows 2000 LAN Manager] . D0 Wed Oct 19 15:41:15 2011 .. DA0 Wed Oct 19 15:41:15 2011 65535 blocks of size 16777216. 65535 blocks available real0m19.628s user0m0.011s sys 0m0.013s Thu Oct 20 11:52:00 CEST 2011 Domain=[PUBLIC] OS=[Windows 2000] Server=[Windows 2000 LAN Manager] . D0 Wed Oct 19 15:41:15 2011 .. DA0 Wed Oct 19 15:41:15 2011 65535 blocks of size 16777216. 65535 blocks available real0m0.063s user0m0.011s sys 0m0.013s Thu Oct 20 11:52:01 CEST 2011 Domain=[PUBLIC] OS=[Windows 2000] Server=[Windows 2000 LAN Manager] . D0 Wed Oct 19 15:41:15 2011 .. DA0 Wed Oct 19 15:41:15 2011 65535 blocks of size 16777216. 65535 blocks available real0m0.058s user0m0.011s sys 0m0.012s Thu Oct 20 11:52:02 CEST 2011 Domain=[PUBLIC] OS=[Windows 2000] Server=[Windows 2000 LAN Manager] . D0 Wed Oct 19 15:41:15 2011 .. DA0 Wed Oct 19 15:41:15 2011 Error in dskattr: NT_STATUS_IO_TIMEOUT real0m20.061s user0m0.010s sys 0m0.012s Thu Oct 20 11:52:23 CEST 2011 Domain=[PUBLIC] OS=[Windows 2000] Server=[Windows 2000 LAN Manager] . D0 Wed Oct 19 15:41:15 2011 .. DA0 Wed Oct 19 15:41:15 2011 65535 blocks of size 16777216. 65535 blocks available real0m1.269s user0m0.011s sys 0m0.013s Thu Oct 20 11:52:25 CEST 2011 Domain=[PUBLIC] OS=[Windows 2000] Server=[Windows 2000 LAN Manager] . D0 Wed Oct 19 15:41:15 2011 .. DA0 Wed Oct 19 15:41:15 2011 65535 blocks of size 16777216. 65535 blocks available real0m0.057s user0m0.010s sys 0m0.012s Thu Oct 20 11:52:26 CEST 2011 Domain=[PUBLIC] OS=[Windows 2000] Server=[Windows 2000 LAN Manager] . D0 Wed Oct 19 15:41:15 2011 .. DA0 Wed Oct 19 15:41:15 2011 65535 blocks
