ReSQL.ru
     
powered by simpleCommunicator - 2.0.38     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Распределение рама Unix
20 сообщений из 45, страница 2 из 2
  2  все
Распределение рама Unix
    #39643843
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Есть СУБД Oracle и есть толпа клиентов.
Клиенты подключаются, пророк создаёт процессы, процессы начинают исполнять запросы.
Соответственно, возникают некие рабочие наборы отображаемой памяти.

Запросы работают относительно быстро, а значит память выделяется и достаточно быстро освобождается, чтобы использоваться другими процессами. Всё хорошо.

"Что-то случилось" и запросы начали исполняться медленнее. Рабочие наборы каждого процесса живут дольше, а значит, при той же нагрузке системе требуется больше (физической) памяти.
Если "немного не рассчитать" с настройками, то после урезания кэшей файловых систем до минимума, операционка может начать высвапливать память процессов.
Своппинг замедлит работу СУБД ещё больше и система может деградировать полностью.

Когда используются большие страницы, то при нехватке ресурсов очередной процесс просто не будет создан: конкретный клиент получит отказ, но система в целом - останется не только работоспособной, но и управляемой.

P.S. Если процесс "намапил от души" (файлов на десятки-сотни гигабайт), это "кэш файловой системы" или "память приложения"? То-то же.
...
Рейтинг: 0 / 0
13.05.2018, 13:59
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39643855
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Basil A. Sidorov, я правильно Вас понимаю, что в линуксе большие страницы невытесняемые в своп, а стандартные - вытесняемые? Ранее в топике говорилось о том, что кэш ФС может скинуть страницы приложения в своп, правда ли это для случая стандартных для x64 страниц 4К?

Про mmap() вопрос провокационный, ибо mmap-ить можно и, например, /dev/zero :)
...
Рейтинг: 0 / 0
13.05.2018, 14:28
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39643967
Фотография Журавлев Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Журавлев Денис
Участник
Вот есть сервер с 16Гигами и есть приложение, которое течет, и за месяц натекает 30 ГБ и что теперь вот эти утекшие страницы никогда не вытеснять в своп? Конечно вытеснять и использовать память для дискового кеша.


В защиту swap'а [в Linux]: распространенные заблуждения https://habr.com/company/flant/blog/348324/
...
Рейтинг: 0 / 0
13.05.2018, 18:58
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39643994
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Scott Tigerв линуксе большие страницы невытесняемые в своп, а стандартные - вытесняемые?Это везде так - крайне непрактично свопить большие куски памяти.
...
Рейтинг: 0 / 0
13.05.2018, 20:12
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644004
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Scott TigerLeonid Kudryavtsev, а известен ли технический способ борьбы с описанным Вами поведением?
в данном случае, на сервере почему то доступ к БД шел через кэш ФС. Когда включили директ ио или асинх ио /подробности не знаю/, доступ к диску из Оракла стал идти минуя кэш ФС - проблема исчезла.

А эффект был красивый. Стабильно проявлялся на запросах к одной большой табличке, все остальные таблички работали нормально, а одна табличка - начинала тупить со страшной силой.

АФАИК раньше в линуксе был параметр swapless, но сейчас вроде его выпилили.
...
Рейтинг: 0 / 0
13.05.2018, 21:26
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644164
Фотография Goofy122
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Goofy122
Участник
Scott TigerGoofy122пропущено...


а как очистить лог/трейс ? И вообще можно ли его очистить ?

Боюсь, этот вопрос я не понял.


В смысле , оракловские процессы растут как грибы после дождя. И все это отражается на diag/rdbms/orcl/trace

Вы это имели ввиду ?

Извиняюсь за глупый вопрос , но можно ли почистить trace файлыи вообще можно ли их очистить то есть удалить ?
...
Рейтинг: 0 / 0
14.05.2018, 09:44
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644220
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Журавлев ДенисВот есть сервер с 16Гигами и есть приложение, которое течет, и за месяц натекает 30 ГБ и что теперь вот эти утекшие страницы никогда не вытеснять в своп?

Идея исправить кривое приложение или вообще заменить его чем-то нормальным Вас не посещала? :)

Журавлев ДенисВ защиту swap'а [в Linux]: распространенные заблуждения https://habr.com/company/flant/blog/348324/

Читал. Сложилось впечатление, что автор подсознательно считает нормальным (!) сам факт наличия конкуренции за память, но не может или не хочет аргументировать свою позицию.
...
Рейтинг: 0 / 0
14.05.2018, 10:35
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644235
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Basil A. SidorovScott Tigerв линуксе большие страницы невытесняемые в своп, а стандартные - вытесняемые?Это везде так - крайне непрактично свопить большие куски памяти.

Нет, не везде, хотя, конечно, вызывает фрагментацию физической памяти с последующей невозможностью собрать большую страницу обратно или ожиданием дефрагментации. Но свопить вообще не практично.
...
Рейтинг: 0 / 0
14.05.2018, 10:46
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644237
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Goofy122Извиняюсь за глупый вопрос , но можно ли почистить trace файлыи вообще можно ли их очистить то есть удалить ?

Спросите лучше в профильном форуме.
...
Рейтинг: 0 / 0
14.05.2018, 10:47
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644247
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Scott TigerBasil A. SidorovЭто везде так - крайне непрактично свопить большие куски памяти.Нет, не вездеСегментная память i80286 сдохла потому, что на диск вытеснялись сегменты, размером до 64 кило байт.
Можете привести пример системы, которая высвопит страницу размером два гига байта?
...
Рейтинг: 0 / 0
14.05.2018, 10:56
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644304
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Basil A. Sidorov, солярис высвопит, но кусочками по 4/8К (на x86/SPARC соответственно). После этого обращение к большой странице потребует её дефрагментации. Нужно понимать, что большие страницы здесь могут быть совершенно для любых целей, например:

Код: plaintext
1.
2.
3.
4.
5.
6.
root@runner2:~# pmap -xasl 15036 | grep 2M
0000000000400000       6144       6144          -          -   2M r-x----  postgres
0000000000E00000       2048       2048       2048          -   2M rw-----    [ heap ]
FFFF80FFBC000000       2048       2048          -          -   2M r-x----  ru_RU.UTF-8.so.3
FFFF80FFBC800000       6144       6144          -          -   2M r-x----  en_US.UTF-8.so.3
FFFF80FFBE800000       2048       2048          -          -   2M r-x----  libcrypto.so.1.0.0
FFFF80FFBF000000       2048       2048          -          -   2M r-x----  libxml2.so.2
...
Рейтинг: 0 / 0
14.05.2018, 11:51
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644341
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
Что-то я не понимаю. Как такое _физически_ на уровне ядра процессора может быть?

Флаг использования и прерывание обращения к странице происходит на уровне записи в таблице страниц.... Если свопим по 4 K, то и кусок памяти соответствующий данной записи должен быть 4 K. Т.е. страница должна быть 4 K.

Масло-масленное получается (((

Мы можем узнать, что у нас не используется большая страница (факт этого мы знаем из записи о странице). Но мы же никак не можем узнать какая именно часть этой страницы не используется.
...
Рейтинг: 0 / 0
14.05.2018, 12:47
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644391
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Leonid Kudryavtsev, а вот так оно устроено - большие страницы представляются как последовательность страниц стандартного размера. См. "Solaris Internals 2nd Edition" (ISBN: 0131482092), раздел 9.10. Сейчас, правда, есть VM2 (Solaris 11.1+), и там может быть по-другому всё, но исходников у меня нет.
...
Рейтинг: 0 / 0
14.05.2018, 13:34
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644470
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
Scott Tigerа вот так оно устроено - большие страницы представляются как последовательность страниц стандартного размераЭто профанация.
Нормальные большие страницы существуют для того, чтобы резко уменьшить накладные расходы диспетчера виртуальной памяти для некоторых сценариев.
Я, конечно, не сомневаюсь, что и у такой эмуляции есть приемлемые сценарии использования, но это не большие страницы.
...
Рейтинг: 0 / 0
14.05.2018, 15:00
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644499
tip78
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tip78
Участник
Scott TigerЖуравлев ДенисВ защиту swap'а [в Linux]: распространенные заблуждения https://habr.com/company/flant/blog/348324/

Читал. Сложилось впечатление, что автор подсознательно считает нормальным (!) сам факт наличия конкуренции за память, но не может или не хочет аргументировать свою позицию.
а как без конкуренции? БД (да любая программа) может её всю сожрать, а всем остальным тоже нужна память.
...
Рейтинг: 0 / 0
14.05.2018, 15:38
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644527
Leonid Kudryavtsev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid Kudryavtsev
Участник
tip78а как без конкуренции? БД (да любая программа) может её всю сожрать
Раньше было такое понятие, как ВЫДЕЛЕННЫЙ сервер.
СУБД память выделили, выделили... сожрет она ее всю или нет - это ее дело. Ресурсы выделены, все работает - вот никто пусть ничего и не трогает.

tip78а всем остальным тоже нужна память.
а все остальные идут лесом и на [некоторое количество] букв
...
Рейтинг: 0 / 0
14.05.2018, 16:39
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644824
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Basil A. SidorovScott Tigerа вот так оно устроено - большие страницы представляются как последовательность страниц стандартного размераЭто профанация.
Нормальные большие страницы существуют для того, чтобы резко уменьшить накладные расходы диспетчера виртуальной памяти для некоторых сценариев.
Я, конечно, не сомневаюсь, что и у такой эмуляции есть приемлемые сценарии использования, но это не большие страницы.

Большие страницы существуют для того, чтобы уменьшить TLB miss ratio для TLB стандартных страниц за счёт уменьшения собственно количества стандартных страниц. Для x64, как пишут (сам не проверял), также измеримо уменьшается вымывание L2-кэша, т.к. TLB стоит между L1- и L2-кэшами.

Относительно "профанации" - почитайте указанную литературу, ISBN я дал, через него PDF гуглится.
...
Рейтинг: 0 / 0
15.05.2018, 11:14
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644827
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
tip78Scott TigerЧитал. Сложилось впечатление, что автор подсознательно считает нормальным (!) сам факт наличия конкуренции за память, но не может или не хочет аргументировать свою позицию.
а как без конкуренции? БД (да любая программа) может её всю сожрать, а всем остальным тоже нужна память.

Что значит "может"? А админ на что? За работой ПО нужно следить и, в том числе, ограничивать его аппетиты, благо в современных ОС таких возможностей хватает.
...
Рейтинг: 0 / 0
15.05.2018, 11:17
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644837
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Leonid Kudryavtsevtip78а как без конкуренции? БД (да любая программа) может её всю сожрать
Раньше было такое понятие, как ВЫДЕЛЕННЫЙ сервер.
СУБД память выделили, выделили... сожрет она ее всю или нет - это ее дело. Ресурсы выделены, все работает - вот никто пусть ничего и не трогает.

Думаете, что-то поменялось? Таки нет :) Там, где так поступали, теперь дают выделенную виртуалку, благо это и дешевле, и быстрее. Особо настырным дают выделенную физику. Был недавно свидетелем, когда приложению, делающему 30 (тридцать) IOPS, выбили отдельную all-flash СХД.
...
Рейтинг: 0 / 0
15.05.2018, 11:24
| Ответить | Цитировать | Написать  
Распределение рама Unix
    #39644851
Ихтиандр
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ихтиандр
Участник
mefmanScott TigerLeonid Kudryavtsev, банальный лог/трейс уже будет потихоньку забивать кэш ФС.
не замечал.
может аптаймы у вас не годами исчисляются
...
Рейтинг: 0 / 0
15.05.2018, 11:37
| Ответить | Цитировать | Написать  
20 сообщений из 45, страница 2 из 2
  2  все
Форумы / Unix-системы [игнор отключен] [закрыт для гостей] / Распределение рама Unix
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=25&msg=39643855&tid=1481342]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 35ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 54ms
get tp. blocked users:
 1ms
others: 265ms
total:  400ms
созд. / загр.: 400ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]