On Wed, 10 Dec 2003, Konstantin Nikonenko wrote:
> Hello oops-users, > > Tuesday, December 9, 2003, 7:07:03 PM, you wrote: > LEK> We have a problem with oops (both 1.5.23 and the cvs version), it died > LEK> a couple hours after it has been started. > LEK> Here is the output of oops.log: > > LEK> [0x19465]run_client(): No mem for header! > LEK> [0x6b1ac]run_client(): No mem for header! > LEK> [0x9a268]fill_mem_obj(): select: timed out. > LEK> [0xbcef3]attach_data(): No mem in attach data. > LEK> [0x5795e]run_client(): No mem for header! > > What gdb is answer on where in core? How many memory oops use? mb No, it just dies without core dumped. Output from top several minutes before it dies: top - 18:31:05 up 18:36, 2 users, load average: 0.57, 0.38, 0.36 Tasks: 699 total, 1 running, 698 sleeping, 0 stopped, 0 zombie Cpu(s): 5.6% us, 2.1% sy, 0.0% ni, 89.4% id, 0.6% wa, 0.1% hi, 2.2% si Mem: 3111636k total, 3025188k used, 86448k free, 239164k buffers Swap: 2097136k total, 0k used, 2097136k free, 1385288k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 70858 oopscach 17 0 2417m 1.1g 3604 S 21.6 37.8 1:07.28 oops 70869 oopscach 15 0 2417m 1.1g 3604 S 21.6 37.8 1:07.28 oops [..more output omitted..] We've set the mem_max and lo_mark to 1024m, but it continue growing after it reached the limit. > needs set limits or more RAM|swap? ulimit: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 8192 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 24575 virtual memory (kbytes, -v) unlimited > > LEK> There's no other messages abnormal, but sometimes with below messages > LEK> from kernel (not always): > > LEK> Dec 8 13:54:05 tproxy1 kernel: oops: page allocation failure. order:3, > mode:0x20 > LEK> Dec 8 13:54:05 tproxy1 kernel: Call Trace: > LEK> Dec 8 13:54:05 tproxy1 kernel: [<c013ac0d>] __alloc_pages+0x2de/0x31c > LEK> Dec 8 13:54:05 tproxy1 kernel: [<c013ac70>] __get_free_pages+0x25/0x3f > LEK> Dec 8 13:54:05 tproxy1 kernel: [<c013e0cd>] cache_grow+0xed/0x345 > > LEK> The swap remain unused at that time. > > LEK> Tested on both kernel 2.4.23 and 2.6.0-test9-mm5, > LEK> glibc-2.2.5, gcc-3.3.2 (gcc-2.95.3 also), Debian GNU/Linux-3.0. > what threads type are u use? $ gcc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs Configured with: ./configure --prefix=/usr/local Thread model: posix gcc version 3.3.2 $ > > LEK> The request rate varies from 100 req/s to 550 req/s. > what hardware u use? IMHO for this requests rate Linux not a best > choise :( MB memory manager really can't allocate memory on this > speed... hmm.. We're running on Dual Xeon 2.8G with HT enabled, 3GB of RAM and the chipset is intel E7501. The kernel is configured with HIGHMEM support(4GB). > > LEK> Any ideas what's wrong? > > -- > Best regards, > Konstantin Nikonenko http://www.kot.dp.ua/ > > ===================================================================== > If you would like to unsubscribe from this list send message to > [EMAIL PROTECTED] with "unsubscribe oops" in message body. > Archive is accessible on http://lists.paco.net/oops-rus/ > ===================================================================== If you would like to unsubscribe from this list send message to [EMAIL PROTECTED] with "unsubscribe oops" in message body. Archive is accessible on http://lists.paco.net/oops-rus/
