Фрагментация памяти в приложении

Автор mihail_1, 10 января 2013, 12:24:55

« назад - далее »

0 Пользователи и 1 гость просматривают эту тему.

mihail_1

При многочисленном использовании в Си функций malloc и free приложение быстро ест память и освобожденная память не возвращается системе.
Приложению она тоже не отдается многократно, поскольку постепено нарезается на мелкие кусочки, которые не склеиваются, а по отдельности малы и выделяется новая память из системы. В своем приложении с этим можно бороться захватив большой кусок и выделяя/освобождая в нем нужные куски для программы. Но как с этим бороться в чужих программах? Проблема сильно выражена в работе mysql.

corner

Попробуйте поиграть с разными значениями vm.overcommit_ratio и vm.overcommit_memory.
Ну и, конечно - mysql perfomance tuning.
Ну а в своих прjграммах, как альтернатива, можно попробовать использовать сторонние библиотеки по работе с памятью. Эти вопросы постоянно муссируются в нете, информации полно.

mihail_1

Со своими приложениями я справился, а с mysql беда.
А если я ограничу количество выделяемой mysql памяти он наверно получив отказ при запросе очередного куска либо не выполнит запрос либо вообще перезагрузится. Это точно не решение. Можно ли чем-то посмотреть во что превращает память mysql и если это последовательные мелкие куски можно ли заставить менеджер памяти склеивать их в один?
Мне нужно не запретить кому-то вешать сервер, а сделать так чтобы mysql работал и не жрал больше чем действительно необходимо. (пожирание предположительно происходит при возврате результатов запроса и настраивать здесь уже нечего)

corner

Здесь  http://dev.mysql.com/doc/refman/4.1/en/memory-use.html смотрели?
Сам я уже больше года с mysql не связываюсь. Памяти хватает. CMS не пишу. Везде удается трансформировать задачи к использованию noSQL.

mihail_1

Проблема не в том что mysql съедает много памяти, а в том что он похоже съедает ее не по делу. Т.е. он ее уже освободил, но вернуть системе не смог и сам использовать еще раз не может. Количество захваченой памяти существенно превышает длинну буферов которые можно настраивать. Я сталкивался с такой проблемой в приложении на Cи ирешил ее только использованием собственной функции выделения памяти в большом вначале захваченном буфере - занимаемая приложением память снизилаь в разы.
Про noSQL я ничего не знаю, и не очень хотелось бы почти законченный проект писавшися больше года начинать с нуля.

Olej

Цитата: mihail_1 от 10 января 2013, 12:24:55
При многочисленном использовании в Си функций malloc и free приложение быстро ест память и освобожденная память не возвращается системе.
Это утверждение не соответствует действительности, см. относительно сляб-алокатора.

Цитата: mihail_1 от 10 января 2013, 12:24:55
В своем приложении с этим можно бороться захватив большой кусок и выделяя/освобождая в нем нужные куски для программы.
Именно так и выделяется память в Linux по умолчанию, даже когда вы запрашиваете 1 байт. Это и есть работа сляб-алокатора.
См.:

bash-4.2$ sudo cat /proc/slabinfo
...
kmalloc-8192          38     44   8192    4    8 : tunables    0    0    0 : slabdata     11     11      0
kmalloc-4096          59     72   4096    8    8 : tunables    0    0    0 : slabdata      9      9      0
kmalloc-2048         224    224   2048   16    8 : tunables    0    0    0 : slabdata     14     14      0
kmalloc-1024         897    912   1024   16    4 : tunables    0    0    0 : slabdata     57     57      0
kmalloc-512         1344   1376    512   16    2 : tunables    0    0    0 : slabdata     86     86      0
kmalloc-256          794    912    256   16    1 : tunables    0    0    0 : slabdata     57     57      0
kmalloc-128         1319   1600    128   32    1 : tunables    0    0    0 : slabdata     50     50      0
kmalloc-64         24713  26432     64   64    1 : tunables    0    0    0 : slabdata    413    413      0
kmalloc-32          6784   6784     32  128    1 : tunables    0    0    0 : slabdata     53     53      0
kmalloc-16          6656   6656     16  256    1 : tunables    0    0    0 : slabdata     26     26      0
kmalloc-8           8704   8704      8  512    1 : tunables    0    0    0 : slabdata     17     17      0
kmalloc-192         7443   7854    192   21    1 : tunables    0    0    0 : slabdata    374    374      0
kmalloc-96          2268   2268     96   42    1 : tunables    0    0    0 : slabdata     54     54      0


corner

Больше уже ничем помочь не могу. Посмотрите на Хабре http://habrahabr.ru/qa/11050/ - там много статей на эту тему.