Re: [PATCH] Re: Shared memory shmat/dt not working well in 2.5.x

[Zlatko Calusic <zlatko.calusic@iskon.hr>]

Zlatko Calusic <zlatko.calusic@iskon.hr> writes:

> Alessandro Suardi <alessandro.suardi@oracle.com> writes:
>> The more complicated bug you're talking about is the exec_mmap
>>   change introduced in 2.5.19 and fixed a handful of versions
>>   later, possibly .28, where PMON wouldn't start after 120"...
>>   I guess :)
>
> Oh, well, if that one is really fixed, then I have another one. ;)
>

Hm, not anymore!

Thanks to you guys, 2.5.41 is flawless. It works under all the tests
that were failing before. Great work!

I did some benchmarks and it looks like 2.5 is a little bit slower.  I
have two small perl+plsql applications for testing purposes,
"cucibench" benches how long it takes to parse cucitail POP daemon log
and put it into database (insert load). "mailproc" processes sendmail
log and does the same. mailproc is a little bit more complicated (it
also does updates). The results are as follows (numbers are
minutes:seconds it took to finish the task on Oracle 9.2.0.1):

| app       | 2.4.19 | 2.5.41 |
|-----------------------------|
| cucibench |  03:17 |  03:38 |
| mailproc  |  02:12 |  02:30 |
|-----------------------------|

I also observed that other application I use occasionally - LXR (Linux
source cross referencing tool) - takes much longer to generate xref
database (which is in Berkeley DB files). It works in three passes,
where the last one, when it dumps symbols into DB, is interesting. In
2.4 it finishes quickly (it uses 100% CPU, then occasionally syncs the
databases - heavy write traffic for a second - then continues), but
2.5 has problems with it (it stucks writing to disk all the time, CPU
usage is minimal and process progresses very slowly). Andrew, if
you're interested I can send you some numbers to describe the case
better.

Keep up the good work!
-- 
Zlatko