forum.opennet.ru - "SLAB проблемы выделения памяти" (8)

форумы

помощь

поиск

регистрация

вход/выход

слежка

"SLAB проблемы выделения памяти"

Форум Открытые системы на сервере (Ядро / Linux)
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"SLAB проблемы выделения памяти"	+/–
Сообщение от LastHappy (ok) on 09-Сен-16, 10:44
Доброго времени суток, комрады! Ломаю голову, не могу понять. Помогите.) Есть сервер на нем огромное кол-во файлов более 30 млн. Так же на нем крутится тяжелая БД (70 Гб) на Mysql + веб-сервер. На борту сервер имеет 32Гб ОЗУ. Проблема заключается в том, что использованная всеми процессами память + free + cached ну и т.д. не равняется общему объему памяти, ну никак. Это вроде как понятно, вся остальная озу в slab, а именно отдана ext4_inode_cache (19 Гб недостающей озу). Серверу БД и прочим процессам периодически начинает не хватать остатка ОЗУ и система начинает активно раздавать память из SWAP, растет wa, следом LA, вообщем картина становится печальной. Причем slab не высвобождает память и ext4_inode_cache даже при нехватке свободной озу начинает уверенно ползти вверх. Собственно, сам вопрос, а точнее несколько: 1. Не многовато ли столько ОЗУ под кеш дискрипторов? 2. Разве slab не должен высвободить необходимую память требующим процессам из этого кеша? 3. И можно ли как-то ограничить его аппетиты, регулируя максимальный размер кеша дескрипторов?
Ответить \| Правка \| Cообщить модератору

Оглавление

SLAB проблемы выделения памяти, aurved, 11:19 , 09-Сен-16, (1)

SLAB проблемы выделения памяти, LastHappy, 11:40 , 09-Сен-16, (3)

SLAB проблемы выделения памяти, aurved, 11:59 , 09-Сен-16, (5) +1

SLAB проблемы выделения памяти, LastHappy, 12:03 , 09-Сен-16, (6)

SLAB проблемы выделения памяти, aurved, 12:18 , 09-Сен-16, (7)

проблемы памяти, Andrey Mitrofanov, 11:24 , 09-Сен-16, (2)

проблемы памяти, LastHappy, 11:47 , 09-Сен-16, (4) –1

проблемы памяти, Andrey Mitrofanov, 12:29 , 09-Сен-16, (8)

Сообщения по теме [Сортировка по времени | RSS]

1. "SLAB проблемы выделения памяти" +/–

Сообщение от aurved on 09-Сен-16, 11:19

sysctl -a | grep -i slab
vm.min_slab_ratio = 5
можно поискать про vm.min_slab_ratio -- например https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Я так понимаю можно сбрасывать slab  и не только его при желании:
drop_caches
Writing to this will cause the kernel to drop clean caches, as well as
reclaimable slab objects like dentries and inodes.  Once dropped, their
memory becomes free.
To free pagecache:
    echo 1 > /proc/sys/vm/drop_caches
To free reclaimable slab objects (includes dentries and inodes):
    echo 2 > /proc/sys/vm/drop_caches
To free slab objects and pagecache:
    echo 3 > /proc/sys/vm/drop_caches
This is a non-destructive operation and will not free any dirty objects.
To increase the number of objects freed by this operation, the user may run
`sync' prior to writing to /proc/sys/vm/drop_caches.  This will minimize the
number of dirty objects on the system and create more candidates to be
dropped.
This file is not a means to control the growth of the various kernel caches
(inodes, dentries, pagecache, etc...)  These objects are automatically
reclaimed by the kernel when memory is needed elsewhere on the system.
Use of this file can cause performance problems.  Since it discards cached
objects, it may cost a significant amount of I/O and CPU to recreate the
dropped objects, especially if they were under heavy use.  Because of this,
use outside of a testing or debugging environment is not recommended.
You may see informational messages in your kernel log when this file is
used:
    cat (1234): drop_caches: 3
These are informational only.  They do not mean that anything is wrong
with your system.  To disable them, echo 4 (bit 3) into drop_caches.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "SLAB проблемы выделения памяти" +/–

Сообщение от LastHappy (ok) on 09-Сен-16, 11:40

> To free slab objects and pagecache:
>  echo 3 > /proc/sys/vm/drop_caches
Никак не влияет на slab. Не выгружается вообще. Что быть не должно

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "SLAB проблемы выделения памяти" +1 +/–

Сообщение от aurved on 09-Сен-16, 11:59

This is a non-destructive operation and will not free any dirty objects.
To increase the number of objects freed by this operation, the user may run
`sync' prior to writing to /proc/sys/vm/drop_caches.  This will minimize the
number of dirty objects on the system and create more candidates to be
dropped.
dirty objects не сбрасывает, советуют sync сделать перед этим

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "SLAB проблемы выделения памяти" +/–

Сообщение от LastHappy (ok) on 09-Сен-16, 12:03

> dirty objects не сбрасывает, советуют sync сделать перед этим
Пофиг:
# vmstat -m | grep ext4_inode_cache
ext4_inode_cache         13826740 13826740    872      4
# sync; echo 3 > /proc/sys/vm/drop_caches
# root@spbratsk:/# vmstat -m | grep ext4_inode_cache
ext4_inode_cache         13827340 13827340    872      4

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "SLAB проблемы выделения памяти" +/–

Сообщение от aurved on 09-Сен-16, 12:18

значит надо искать в другом месте, а что насчет vm.vfs_cache_pressure, какое значение?
может поискать -- ext4 inode cache slab?

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

2. "проблемы памяти" +/–

Сообщение от Andrey Mitrofanov on 09-Сен-16, 11:24

> Доброго времени суток, комрады!
> Ломаю голову, не могу понять. Помогите.)
> Есть сервер на нем огромное кол-во файлов более 30 млн. Так же
> на нем крутится тяжелая БД (70 Гб) на Mysql + веб-сервер.
> На борту сервер имеет 32Гб ОЗУ.
> Проблема заключается в том, что использованная всеми процессами память + free +
> cached ну и т.д. не равняется общему объему памяти, ну никак.
Потому, что их всех не надо складывать. Они не складываются потому что пересекаются. Это сложно и непонятно, в это надо просто Верить!  (Но у меня обычно получается больше физ.объёма -- вероятно, от характера задач ~см.ниже.)
Скажем, "чистые" кеши считаются и свободной памятью, а shared память нескольких форков одного демона БД физически суть одна (по большей части?). Но посчитать и увидеть это... сложно. "Товарищь, верь!"
> Это вроде как понятно, вся остальная озу в slab, а именно
Это, вроде как, понятно -- фантазирование... Пустое это. //Оставляю за собой право ошибаться -- понятно№2.
> отдана ext4_inode_cache (19 Гб недостающей озу).
> Серверу БД и прочим процессам периодически начинает не хватать остатка ОЗУ и
У меня для сервера "в большой части БД" экстенсивное решение было -- больше ОЗУ, чтоб и сервисам памяти хватало, и _БД_ в файловом кеше ОС помещалась целиком (повторяю: экстенсивный путь!). (Мелочи типа устоявшейся и максимальной нагрузки на дисковый io не рассматриваем.)
Типа, база 60-75Гб vs ОЗУ 96ГБ - оки, база подросла до 75-90ГБ - "чётт жмёт, поскрипывает, проседает" (там и iops-ы тож подросли, поприжались). Новый сервер со 128ГБ ОЗУ (и шпинтелями-дисками числом и скоростью поболе, да) --> стало "вааще всё зашибись" (ну, индексы пухнут, фрагментация таблиц увеличивает iops-ы под той же устоявшейся нагрузкой  --  но, опять, не суть).
> система начинает активно раздавать память из SWAP, растет wa, следом LA,
Что нужно файловому серверу "с миллионами файлов" (и неизвестным характером нагрузки) я не знаю. Может быть, просто селить нагруженные шары на одном сервере с нагруженной БД и недостатком ресурсов -- плохая идея. Может быть, оно будет "заваливаться" то в одну, то в другую сторону...  Но, вполне допускаю, что найдётся кто-нибудь из коллег, кто поделится, что нужно и для такого сочетания, как его померить, выстроить и обеспечить ресурсами.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "проблемы памяти" –1 +/–

Сообщение от LastHappy (ok) on 09-Сен-16, 11:47

> Это, вроде как, понятно -- фантазирование... Пустое это. //Оставляю за собой право
> ошибаться -- понятно№2.
Ну а что тут не понятного? Политика системы такова, зачем простаивать ресурсам, если их можно пустить на благо, утилизировать, например, на файловый кеш, чем и занимается slab. Но почему он не высвобождает? Вот в чем вопрос. По описанию, должен.
Даже echo 3 > /proc/sys/vm/drop_caches никак не влияет на него. Вообще ни байта не выгружает из кеша дискрипторов.
> Типа, база 60-75Гб vs ОЗУ 96ГБ - оки, база подросла до 75-90ГБ
> - "чётт жмёт, поскрипывает, проседает" (там и iops-ы тож подросли, поприжались).
> Новый сервер со 128ГБ ОЗУ (и шпинтелями-дисками числом и скоростью поболе,
> да) --> стало "вааще всё зашибись" (ну, индексы пухнут, фрагментация таблиц
> увеличивает iops-ы под той же устоявшейся нагрузкой  --  но,
> опять, не суть).
Ну постоянное наращивание ресурсов тоже не панацея. Тут явно какой-то баг. Система ведет себя не так, как должна.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "проблемы памяти" +/–

Сообщение от Andrey Mitrofanov on 09-Сен-16, 12:29

>> Это, вроде как, понятно -- фантазирование... Пустое это. //Оставляю за собой право
>> ошибаться -- понятно№2.
> Ну а что тут не понятного? Политика системы такова, зачем простаивать ресурсам,
Не понятно мне -- я просто не вчитывался в Ваш вопрос, силы экономил. Но, если Вы так говорите, верю, что всё совсем не так, как я {при,по}думал. У вас там, сложно и пр.
>> Типа, база 60-75Гб vs ОЗУ 96ГБ - оки, база подросла до 75-90ГБ
>> Новый сервер со 128ГБ ОЗУ (и шпинтелями-дисками числом и скоростью поболе,
>Тут явно какой-то баг. Система ведет себя не так, как должна.
Откуда знаете, как _она_ должна вести, когда она ведёт себя вот так, как ведёт? Ну, то есть -- есть, что предъявить => баги в багитрекеры.  Нет чего предъявить -- вопросы в форумы под флагом "желаю, чтобы всем"?
По мне, так всё просто: есть ресурсы - работает ("так надо"),
Нет ресурсов - своп, тормоза и пр. Я=так надо, но я не заморачиваюсь, Вы=это ж баг.
Мммм... Затруднение?  Ядерщики в доме есть? ///SLAB же всё портит, срочно нужны патчи. Ау!!

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "SLAB проблемы выделения памяти"	+/–
Сообщение от aurved on 09-Сен-16, 11:19
sysctl -a \| grep -i slab vm.min_slab_ratio = 5 можно поискать про vm.min_slab_ratio -- например https://www.kernel.org/doc/Documentation/sysctl/vm.txt Я так понимаю можно сбрасывать slab и не только его при желании: drop_caches Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free. To free pagecache: echo 1 > /proc/sys/vm/drop_caches To free reclaimable slab objects (includes dentries and inodes): echo 2 > /proc/sys/vm/drop_caches To free slab objects and pagecache: echo 3 > /proc/sys/vm/drop_caches This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped. This file is not a means to control the growth of the various kernel caches (inodes, dentries, pagecache, etc...) These objects are automatically reclaimed by the kernel when memory is needed elsewhere on the system. Use of this file can cause performance problems. Since it discards cached objects, it may cost a significant amount of I/O and CPU to recreate the dropped objects, especially if they were under heavy use. Because of this, use outside of a testing or debugging environment is not recommended. You may see informational messages in your kernel log when this file is used: cat (1234): drop_caches: 3 These are informational only. They do not mean that anything is wrong with your system. To disable them, echo 4 (bit 3) into drop_caches.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "SLAB проблемы выделения памяти"	+/–
	Сообщение от LastHappy (ok) on 09-Сен-16, 11:40
	> To free slab objects and pagecache: > echo 3 > /proc/sys/vm/drop_caches Никак не влияет на slab. Не выгружается вообще. Что быть не должно
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	5. "SLAB проблемы выделения памяти"	+1 +/–
	Сообщение от aurved on 09-Сен-16, 11:59
	This is a non-destructive operation and will not free any dirty objects. To increase the number of objects freed by this operation, the user may run `sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the number of dirty objects on the system and create more candidates to be dropped. dirty objects не сбрасывает, советуют sync сделать перед этим
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "SLAB проблемы выделения памяти"	+/–
	Сообщение от LastHappy (ok) on 09-Сен-16, 12:03
	> dirty objects не сбрасывает, советуют sync сделать перед этим Пофиг: # vmstat -m \| grep ext4_inode_cache ext4_inode_cache 13826740 13826740 872 4 # sync; echo 3 > /proc/sys/vm/drop_caches # root@spbratsk:/# vmstat -m \| grep ext4_inode_cache ext4_inode_cache 13827340 13827340 872 4
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "SLAB проблемы выделения памяти"	+/–
	Сообщение от aurved on 09-Сен-16, 12:18
	значит надо искать в другом месте, а что насчет vm.vfs_cache_pressure, какое значение? может поискать -- ext4 inode cache slab?
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору

2. "проблемы памяти"	+/–
Сообщение от Andrey Mitrofanov on 09-Сен-16, 11:24
> Доброго времени суток, комрады! > Ломаю голову, не могу понять. Помогите.) > Есть сервер на нем огромное кол-во файлов более 30 млн. Так же > на нем крутится тяжелая БД (70 Гб) на Mysql + веб-сервер. > На борту сервер имеет 32Гб ОЗУ. > Проблема заключается в том, что использованная всеми процессами память + free + > cached ну и т.д. не равняется общему объему памяти, ну никак. Потому, что их всех не надо складывать. Они не складываются потому что пересекаются. Это сложно и непонятно, в это надо просто Верить! (Но у меня обычно получается больше физ.объёма -- вероятно, от характера задач ~см.ниже.) Скажем, "чистые" кеши считаются и свободной памятью, а shared память нескольких форков одного демона БД физически суть одна (по большей части?). Но посчитать и увидеть это... сложно. "Товарищь, верь!" > Это вроде как понятно, вся остальная озу в slab, а именно Это, вроде как, понятно -- фантазирование... Пустое это. //Оставляю за собой право ошибаться -- понятно№2. > отдана ext4_inode_cache (19 Гб недостающей озу). > Серверу БД и прочим процессам периодически начинает не хватать остатка ОЗУ и У меня для сервера "в большой части БД" экстенсивное решение было -- больше ОЗУ, чтоб и сервисам памяти хватало, и _БД_ в файловом кеше ОС помещалась целиком (повторяю: экстенсивный путь!). (Мелочи типа устоявшейся и максимальной нагрузки на дисковый io не рассматриваем.) Типа, база 60-75Гб vs ОЗУ 96ГБ - оки, база подросла до 75-90ГБ - "чётт жмёт, поскрипывает, проседает" (там и iops-ы тож подросли, поприжались). Новый сервер со 128ГБ ОЗУ (и шпинтелями-дисками числом и скоростью поболе, да) --> стало "вааще всё зашибись" (ну, индексы пухнут, фрагментация таблиц увеличивает iops-ы под той же устоявшейся нагрузкой -- но, опять, не суть). > система начинает активно раздавать память из SWAP, растет wa, следом LA, Что нужно файловому серверу "с миллионами файлов" (и неизвестным характером нагрузки) я не знаю. Может быть, просто селить нагруженные шары на одном сервере с нагруженной БД и недостатком ресурсов -- плохая идея. Может быть, оно будет "заваливаться" то в одну, то в другую сторону... Но, вполне допускаю, что найдётся кто-нибудь из коллег, кто поделится, что нужно и для такого сочетания, как его померить, выстроить и обеспечить ресурсами.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "проблемы памяти"	–1 +/–
	Сообщение от LastHappy (ok) on 09-Сен-16, 11:47
	> Это, вроде как, понятно -- фантазирование... Пустое это. //Оставляю за собой право > ошибаться -- понятно№2. Ну а что тут не понятного? Политика системы такова, зачем простаивать ресурсам, если их можно пустить на благо, утилизировать, например, на файловый кеш, чем и занимается slab. Но почему он не высвобождает? Вот в чем вопрос. По описанию, должен. Даже echo 3 > /proc/sys/vm/drop_caches никак не влияет на него. Вообще ни байта не выгружает из кеша дискрипторов. > Типа, база 60-75Гб vs ОЗУ 96ГБ - оки, база подросла до 75-90ГБ > - "чётт жмёт, поскрипывает, проседает" (там и iops-ы тож подросли, поприжались). > Новый сервер со 128ГБ ОЗУ (и шпинтелями-дисками числом и скоростью поболе, > да) --> стало "вааще всё зашибись" (ну, индексы пухнут, фрагментация таблиц > увеличивает iops-ы под той же устоявшейся нагрузкой -- но, > опять, не суть). Ну постоянное наращивание ресурсов тоже не панацея. Тут явно какой-то баг. Система ведет себя не так, как должна.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	8. "проблемы памяти"	+/–
	Сообщение от Andrey Mitrofanov on 09-Сен-16, 12:29
	>> Это, вроде как, понятно -- фантазирование... Пустое это. //Оставляю за собой право >> ошибаться -- понятно№2. > Ну а что тут не понятного? Политика системы такова, зачем простаивать ресурсам, Не понятно мне -- я просто не вчитывался в Ваш вопрос, силы экономил. Но, если Вы так говорите, верю, что всё совсем не так, как я {при,по}думал. У вас там, сложно и пр. >> Типа, база 60-75Гб vs ОЗУ 96ГБ - оки, база подросла до 75-90ГБ >> Новый сервер со 128ГБ ОЗУ (и шпинтелями-дисками числом и скоростью поболе, >Тут явно какой-то баг. Система ведет себя не так, как должна. Откуда знаете, как _она_ должна вести, когда она ведёт себя вот так, как ведёт? Ну, то есть -- есть, что предъявить => баги в багитрекеры. Нет чего предъявить -- вопросы в форумы под флагом "желаю, чтобы всем"? По мне, так всё просто: есть ресурсы - работает ("так надо"), Нет ресурсов - своп, тормоза и пр. Я=так надо, но я не заморачиваюсь, Вы=это ж баг. Мммм... Затруднение? Ядерщики в доме есть? ///SLAB же всё портит, срочно нужны патчи. Ау!!
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору