Per, > set-variable = key_buffer=16M > set-variable = sort_buffer=1M > set-variable = record_buffer=1M > set-variable = max_allowed_packet=16M > set-variable = thread_stack=256K > set-variable = innodb_log_file_size=32M > set-variable = innodb_log_buffer_size=8M > > set-variable = innodb_buffer_pool_size=950M > set-variable = innodb_additional_mem_pool_size=128M
these look ok, you should be able to make safely at least 300 connections without memory consumption approaching 2 GB. But I tested your my.cnf on our computer, and InnoDB Monitor reported the following when I had the standard test set of some 15 threads running: ... Total memory allocated 1214054564; in additional pool allocated 743552 ... Looks like in your case InnoDB has allocated a lot of memory also outside the additional mem pool, and it crashes when it has allocated about 1400 000 000 bytes. Actually, because of memory fragmentation, the 200 MB which InnoDB in your case has allocated from the operating system may in reality take a lot more space. As long as InnoDB allocates from its own additional_mem_pool, we know exactly how much memory is used. But when InnoDB has to resort to allocation with normal malloc(), we do not know any more what is the real memory usage inside glibc. Why does InnoDB allocate so much memory in your case? If you follow the memory allocation with innodb_monitor, does the allocation grow steadily over days? Then it could be a memory leak in InnoDB. > > Could it be that the mysqld memory usage may approach 2 GB? In that case > > glibc will start allocating memory over thread stacks, which will cause all > > kinds of crashes and errors. > > Hmm. I thought the heap could grow up to 3GB on Linux 2.4 (with one > gigabyte for stack). Is the memory space split 2/2? This is bad news for > me - I need as much memory as I can get. Well, I think it is 2 GB user memory. Better Linux experts please correct me if I am wrong. Here I found some patch you can use to get even 3.5 GB user memory: http://marc.theaimsgroup.com/?l=linux-kernel&m=101081428112601&w=2. > > The trace above is sensible. Do you have a BLOB or TEXT column in the table > > where it is doing an insert? > > No. Its mostly varchars. > > > If not, then the index entry tuple which InnoDB has just constructed > > has probably garbage in its fields, and that is why InnoDB believes it > > is a 'big record'. > > Hmm. So, if the heap has grown to much - glibc is writing garbage all > over the stack. Is there any way to tell how much memory MySQL has > allocated? You can calculate it approximately from the formula in InnoDB manual, section 2. Hmm.. what to do? 1) Monitor the memory consumption with innodb_monitor. Is there a symptom of a memory leak? 2) Try a smaller buffer pool or bigger. Does the crash always happen when InnoDB has allocated about 1400 MB of memory? 3) Try setting innodb_additional_mem_pool much bigger, say, 400 MB. Does memory allocation still spill over from it? 4) Run inside gdb so that we get a bt full of the crash. 5) I will add some assertions to 3.23.52 which should catch the garbage in the index entry earlier, and will also print diagnostics about the garbage. 6) I will run tests with InnoDB memory debugging switched on, and look if I can find some memory leak or memory overwrite. > -- > Per Andreas Buer Best regards, Heikki Innobase Oy --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
