So far I have seen this issue on VMWare WS 7 and ESX 5. I haven’t tested
on physical hardware yet but maybe the issue happens there as well, I
will try to test it.
Installed a default sles10sp4-64 (default kernel) in a VM and things
were fine, performance in Gnome is normal, i.e. desktop loads in a
normal time and apps start OK, terminal prompt can be shown almost
immediately etc.
I applied all current patches, but now, showing the desktop is much
slower, and launching any application (even terminal) takes much
longer for the first-time launch. e.g. terminal can take several seconds
to launch the first time, but is faster thereafter. “top” shows high CPU
util of related processes (whichever process I happen to be launching).
I haven’t done much testing at a text console (i.e. outside of the GUI)
so I can’t say if the performance issue is a global one or just confined
to the GUI environment.
Thanks if anyone has any hints, and I will try to test on physical
hardware as well.
Weird, adding more RAM to the ESX server has resolved the issue; but
it’s strange, because as I said in the OP, performance was quite alright
unpatched and became much worse after patching, and no other things were
changed.
Anyway, if I have any more findings I will post back.
Weird, adding more RAM to the ESX server has resolved the issue; but
it’s strange, because as I said in the OP, performance was quite alright
unpatched and became much worse after patching, and no other things were
changed.
Anyway, if I have any more findings I will post back.
Regards
GM[/color]
Strange indeed & will keep an eye out. At the two sites I’ve been that
already have vSphere 5.0 running (upgraded from 4.x) and also SLES 10
SP3+post patches (sorry, no SP4 there yet) I have not seem this. All is
working speedy.
One difference could be, I always use the smp kernel with SLES 10 64bit
(even when running singlecore VM’s).
I have seen some serious slowdowns in GNOME on desktops where resolving
was going wrong because /etc/hosts had a wrong, or was missing a correct
entry for localhost. I don’t remember. Not likely that is what you are
seeing, but thought I’d mention it as one of those shots in the dark.
-Willem
–
Novell Knowledge Partner (voluntary sysop)
It ain’t anything like Harry Potter… but you gotta love the magic IT
can bring to this world
You might me onto something with the smp kernel; I tried this again on
VMWare WS and same problem…when I switched to SMP kernel, performance
was much better. I will try to narrow down specifically which update
introduces the performance issue with default kernel,
OK, I got it. It’s because I was using zypper up to apply patches from a
local repo, and it does not run SuSEconfig at the end. Whereas, if I use
YOU, then it does run SuSEconfig, hence the inconsistent results I was
getting.
I repeated the patching with zypper up, then ran SuSEconfig, then the
performance is good again. Obviously, SuSEconfig is doing something
important!! To completely pin it down, I’d have to figure out which
things were changed by SuSEconfig but I’m happy for the moment. Doing a
search, it seems many people ask the question “should I run SuSEconfig
after zypper up”, I guess the asnwer is yes in the case of sles10.
There’s some discussion in bugzilla about this (zypper not running
suseconfig).
OK, I got it. It’s because I was using zypper up to apply patches from a
local repo, and it does not run SuSEconfig at the end. Whereas, if I use
YOU, then it does run SuSEconfig, hence the inconsistent results I was
getting.
I repeated the patching with zypper up, then ran SuSEconfig, then the
performance is good again. Obviously, SuSEconfig is doing something
important!! To completely pin it down, I’d have to figure out which
things were changed by SuSEconfig but I’m happy for the moment. Doing a
search, it seems many people ask the question “should I run SuSEconfig
after zypper up”, I guess the asnwer is yes in the case of sles10.
There’s some discussion in bugzilla about this (zypper not running
suseconfig).[/color]
Note zypper is only provided in SLES10 as a technology preview (ahead of
inclusion in SLES11) and is not the supported method for applying
updates - you should instead be using rug.
HTH.
Simon
Novell Knowledge Partner (NKP)
Do you work with Novell technologies at a university, college or school?
If so, your campus could benefit from joining the Novell Technology
Transfer Partner (TTP) program. See TTP Organization | Micro Focus for more details.
OK thanks; my experience with rug/zmd is less than favourable
(particularly, the zmd service has an annoying habit of dying or
becoming unresponsive). Hence my experimentation with zypper on sles10.
Actually, I find that zypper also does not run SuSEconfig in sles11sp1.
Whether that has any impact or not, or whether it’s best practice to
follow a zypper up with a SuSEconfig, I am unsure - options seem to be
“yes” or “no harm to do so” (therefore yes). Anyway, what I will
probably do henceforth is use YOU since it runs SuSEconfig after
patching.