Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I got some email from one of my coworkers in Toronto that they were=20 having some memory allocation issues in RHEL4. The program is a simpleC++ that uses the C++ new operator to allocate a=20 character array: new char[chunk]; Where chunk is 10240. The results shown below are the ones I got from=20 my coworker, but I repeated the test and got similar results. (I'll send the C++ code if anyone wants to reproduce it.). The=20 underlying problem is that they are having issues with our product=20 running out of memory on RHEL 4.0 and 5.2. I'd like to be able to=20 explain what the differences are between RHEL 3 (2.4.21 kernel) and RHEL = 4 (2.6.9 kernel). HOW TO REPRODUCE: Both systems are Xeons with 4GB. system1 is RHEL 3.0 Update 1 system2 is RHEL 4.0 Update 5 1) Compile the attached program on a rhel-3 machine. Compiler is gcc-3.3.3 in both cases, not the installed compiler. The executable was built on system1 and run on both systems. A second test where the program was compiled on system2 with the same=20 compiler produced the same results as the original test on system2. Both systems are 32-bit, both suport=20 pae, and both are single-core multiple processors with 4GB memory. The compile command was: /<location>/gcc-3.3.3/bin/g++ testMem.C -o testM= em Results on system1 (RHEL 3.0) Allocating: 10240 bytes, 100 times. proc size at start =3D 790528 proc size at end =3D 1363968: numPages =3D 333 PageSize =3D 4096 proc grew by =3D 573440 total number of pages =3D 140 *Allocating: 1024000 all at once. * total process grew by: 4096 * total number of pages =3D 1 =20 Results on system2 (RHEL 4.0) Allocating: 10240 bytes, 100 times. proc size at start =3D 3350528 proc size at end =3D 4358144: numPages =3D 1064 PageSize =3D 4096 proc grew by =3D 1007616 total number of pages =3D 246 *Allocating: 1024000 all at once. * total process grew by: 1028096 * total number of pages =3D 251 --=20 Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org> Boston Linux and Unix PGP key id: 537C5846 PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB CA3B 4607 4319 537C 5846
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |