06Jun2008 (UTC +8)
On 6/2/08, thad <[EMAIL PROTECTED]> wrote:
> Semi-OT reply but could be related.Are you using LVM?
Hmmm... I did see an LVM related message upon boot-up (can't remember
what it was though), but no, I didn't intentionally install it.
> If you are using LVM, I got same issue on another UNIX OS (AIX) and we
> found out the system is hitting paging logical volume (lv) (read
> pegging to 80-100%) instead of the lvs for Oracle. We re-layout the
> paging into 3 separate lv of equal size and do some virtual memory
> parameter and kernel tunings as per that OS and Oracle recommendation.
>
> Look at your iostat which file system its hitting and you could do
> perf tuning as per RHEL recommendation. NMON would be a great tool to
> use it also works on Linux and we also use filemon(though not sure if
> this available for Linux) parse its output with a perl utility
> filemon.pl and thats when we i identified that our wait state is
> hitting the paging and also confirmed that its not bottlenecking on
> physical volume layer.
filemon.pl ? That tool was available also for the Solaris {SPARC,x86}
too, wasn't it? I think I remember using that 11 years ago :)
Anyway, iostat(1) on RHEL 5.1 (fresh install, unpatched) would tell me
that my /dev/hda2 (i.e. /dev/dm-0) and /dev/hdb1 (ie. /dev/dm-1) were
at 100% utilization. Top(1) would show that all my CPUs were pegged
with 100% wait states. It was pretty insane.
Then I saw that multiple processes of kryptd were hogging the CPUs. In
the background, I was mkfs'ing a 500GB SATA2 HDD with XFS, while the
1TB SATA2 HDD (both set at 3Gb i/o speeds) were mkfs'ed with EXT3. And
oh yeah, I was also burning to DVD a copy of the Solaris 10 x86
installer (yeah, I got a license for that too ;) with a SATA2 DVD
writer too (all three SATA2 channels on the motherboard are taxed).
Using taskset(1), I checked each of the kcryptd's CPU affinity, and
found out that they would each bind themselves automagically to one
selected CPU. That wasn't funny. I did remember then that in Fedora 8,
the kryptd's CPU affinity mask was set to F, or bound to all CPU's. So
I manually taskset'ed each kcryptd to only three CPUs, and reserved
one CPU for me, then lo and behold! My system became more stable.
I tried to live with RHEL 5.1 for most of the night, hacking up a
script to manually bind any krcyptd that I find to three CPU's, but
that was annoying. So I could just get on with my life, I went with
Fedora 9, installed VMware on it and everything else I wanted, patched
it all up, and never looked back. Using my Fedora 9 right now, there's
no performance hit at all that can be felt --unless I do my strings(1)
then grep(1) on 100+GB files again, but that's another story.
And of course I checked kcryptd behavior on my current Fedora 9.
They're all set with CPU affinity mask of F.
> On Sun, Jun 1, 2008 at 1:05 PM, Drexx Laggui [personal] <[EMAIL PROTECTED]>
> wrote:
> > The wait states of Red Hat Enterprise v5.1 x86_64 is unbearable with
> > CryptLUKS (on SATA2 1TB HDD's) --and I haven't even installed VMware
> > 1.0.5 yet! It was so terrible that my machine would hang several
> > times, and eventually crash. 4GB RAM and 2.4GHz quad-core CPU were
> > whipped. Used top and iostat to monitor what I could. Anybody
> > experienced the same thing?
> >
> > Thought I'd migrate from Fedora 8 to RHEL 5. Bad move that cost me a
> > weekend++. I'm back to Fedora 9 now though, so everything has been
> > working like a charm again, even VMware 1.0.6 (with Windows XP SP1,
> > Solaris 10, OpenSolaris 05.2008, SLAX's BackTrack v3, all operational
> > simultaneously).
Drexx Laggui -- CISA, CISSP, CFE Associate, ISO27001 LA, CCSI, CSA
http://www.laggui.com ( Singapore / Manila / California )
Computer forensics; Penetration testing; QMS & ISMS developers; K-Transfer
PGP fingerprint = 6E62 A089 E3EA 1B93 BFB4 8363 FFEC 3976 FF31 8A4E
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
http://lists.linux.org.ph/mailman/listinfo/plug
Searchable Archives: http://archives.free.net.ph
