Re: freeze under heavy load

I ran my script of "convert" commands some more.
This is in a folder holding 12000 JPEG's, and
using convert to add a little text "timestamp"
to the frames.
My script is just a list of 4500 convert commands.

I don't see the convert commands building up.
Just one at a time running.
I do worry that /proc/cpuinfo reports:

> processor       : 0
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 127
> model name      : AMD Athlon(tm) 64 Processor 3500+
> stepping        : 1
> cpu MHz         : 1000.000
> cache size      : 512 KB
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 1
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow up pni cx16 lahf_lm svm extapic cr8_legacy misalignsse
> bogomips        : 2047.09
> TLB size        : 1024 4K pages
> clflush size    : 64
> cache_alignment : 64
> address sizes   : 40 bits physical, 48 bits virtual
> power management: ts fid vid ttp tm stc 100mhzsteps

when this is supposed to be a 2.2GHz CPU.

I set up an ext3 filesystem on a new disk, and got similar freezes.
I then made an XFS filesystem on the new disk, same results.

So far, I conclude:

    1) It is not the disk.  Same problem, two different disks
    2) It is not a bug in the filesystem,
             same problem, two filesystems

Does anybody know of a way I can do some sort of kernel
debugging to find out where this is freezing?
Some sort of logging/profiling perhaps?

BTW:  XFS does seem more efficient in some ways.  Lower CPU load
       on rsync, and no significant time in IO-wait state
       when reading/writing scores of files every second.
       I did not test throughput, but CPU load was definately lower than 
ext3

                 aaron
_______________________________________________
NMLUG mailing list
[email protected]
http://lists.b9.com/cgi-bin/mailman/listinfo/nmlug