performance of multithreading gets gradually worse under gdb
Michael Snyder
msnyder@vmware.com
Wed Feb 2 20:28:00 GMT 2011
Markus Alber wrote:
> Hello,
>
> I have experienced the following problem:
>
> I'm debugging a number-crunching application which spawns a lot (36)
> little
> worker threads per iteration. The system does typically OoM 200
> iterations.
> Although each of them should take about the same amount of time, the
> performance
> gets worse with every iteration and becomes excruciatingly slow.
>
> A system monitor reveals that gdb allocates more memory with every
> iteration,
> i.e. with every 36 threads started and finished. The CPU load of GDB
> goes up, too.
> The CPU usage of the application goes down. Compared to the solo
> performance, it
> gets slower by a factor 20 and more, if run long enough.
>
> The application behaves perfectly when run by itself. The
> multi-threaded part is not
> debugging compiled when this behaviour occurs.
>
> The distribution is SuSE 11.3 / gdb 7.1.
>
> Is there anything I can change about this behaviour, any options of gdb
> that need to
> be set in these circumstances?
Interesting.
By how much does gdb's memory allocation increase?
In total or, if possible, per iteration? This might
give is a clue as to where to look.
Do you think you could write a simple sample program that
allocates threads in a manner similar to your application?
Thanks,
More information about the Gdb
mailing list