LINUX.ORG.RU

Проблема с производительностью при нагрузке

 , , ,


0

1

Имеется скрипт location_import.py. Он с openstreetmap заливает в базу информацию(postgre). Всё это происходит в двух разных контейнерах docker. Далее информация htop и iotop не в контейнерах, а непосредственно в машине:

htop имеет вид: https://ibb.co/Yp1psp2

iotop имеет вид: https://ibb.co/KWnNJDk

Конфиг postgresql в контейнере имеет вид:

max_connections = 9999
shared_buffers = 7936MB
effective_cache_size = 23808MB
maintenance_work_mem = 1984MB
checkpoint_completion_target = 0.7
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 4
effective_io_concurrency = 2
work_mem = 406kB
min_wal_size = 1GB
max_wal_size = 4GB


temp_buffers = 1024MB
wal_writer_delay = 500ms
commit_delay = 10000
max_wal_size = 4880MB
random_page_cost = 1.1
track_activity_query_size = 16384
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum = on

В чём суть проблемы? Скрипт выжирает 30гб озу + 20гб свопа. При этом машина при работе скрипта становится неюзабельной ВООБЩЕ. Консоль открывается по хоткею по 10 секунд. Между нажатием клавиш и отрисовкой в консоли по 20 и более секунд. Курсор мыши заикается. После отработки скрипта машина все так же неюзабельна. Фаерфокс дохнет. Делаю killall -9 firefox-esr, потом опять запускаю его - запускается 10 минут. Некоторое время работает postgresql autovacuum, но после его отработки системе не легчает. Система некоторое время рассвопливается, но после рассвопливания и освобождения озу ей опять не легчает. Тег в dwm может переключаться 30 секунд. Любое действие - начинает таращить винт(что-то свопит что-то рассвопливает). В общем беда :). В скрипте postgresql стоит

rec = cur.fetchall()

возможно в этом причина того, что location_import.py выедает ~40гб(9.6гб выедает postgresql в контейнере). Возможно как-то можно проитерировать результат, чтобы в rec не попадал весь результат, но это одна грань этой печали. С остальными вопросами как быть? Что показать?

sysctl -a –> https://paste.ubuntu.com/p/q5d8smQMwp/

★★★

Последнее исправление: serg002 (всего исправлений: 1)

выжирает … 20гб свопа

Надо же, диск кардинально медленнее оперативной памяти. Кто бы мог подумать?

anonymous
()

В чём суть проблемы? Скрипт выжирает 30гб озу + 20гб свопа.

Очевидно, в скрипте баг или жутко неоптимальный алгоритм.

При этом машина при работе скрипта становится неюзабельной ВООБЩЕ.

У тебя, считай, кусок HDD или SSD используется вместо оперативной памяти. Даже современные быстрые SSD значительно медленнее оперативной памяти, с этим ничего не поделать.

После отработки скрипта машина все так же неюзабельна. Фаерфокс дохнет. Делаю killall -9 firefox-esr, потом опять запускаю его - запускается 10 минут. Некоторое время работает postgresql autovacuum, но после его отработки системе не легчает. Система некоторое время рассвопливается, но после рассвопливания и освобождения озу ей опять не легчает. Тег в dwm может переключаться 30 секунд. Любое действие - начинает таращить винт(что-то свопит что-то рассвопливает).

Когда системе не хватает памяти для приложений, она не только обычные данные выталкивает в своп, она ещё и убирает закешированные данные (page cache). В этом кеше много чего лежит, включая часто используемые файлы, данные из memory-mapped файлов, включая бинарники и либы всех запущенных приложений.

Так что даже после полного освобождения свопа, систему ещё какое-то время «не отпускает», пока все данные и код снова не попадут в кеши.

Also see https://en.wikipedia.org/wiki/Thrashing_(computer_science).

Если очень хочется, то можно запретить системе выталкивать страницы памяти определённых приложений в своп. Делается это при помощи mlock. Но пользоваться этим надо осторожно, так как многие выделяют память с запасом и используют не всю.

im-0
()
Последнее исправление: im-0 (всего исправлений: 1)

Данные нужно небольшими чанками качать, обрабатывать и складывать в базу, а не тащить сразу всё, пытаться переживать и выжирать все ресурсы при этом.

В общем, скрипт необходимо переписать.

serioja
()
Ответ на: комментарий от anonymous

https://pkgs.org/search/?q=ulatency

Что ulatency?

У топикстартера проблема в том, что скрипт пытается 40 гигабайт данных положить в 30 гигабайт ОЗУ. cgroups и прочие ухищрения максимум помогут убить скрипт до того, как он выжрет все ресурсы. На этом всё.

im-0
()
Ответ на: комментарий от im-0

Жостко тупишь. Через cgroups можно ограничить для этого скрипта все ресурсы системы, чтобы часть оставалась для других программ.

anonymous
()
Ответ на: комментарий от im-0

cgroups и прочие ухищрения максимум помогут убить скрипт

Совершенно верно. Они этим и не занимаются. А чем они занимаются? Алло?

anonymous
()
Ответ на: комментарий от anonymous

Вопрос не в том чтобы кого то ограничить, а в том, как впихнуть невпихуемое.

И ещё, свопинг это i/o ядра и насколько я знаю ядру нельзя зажать лимиты i/o чтобы контейнер свопился только тогда, когда процессам системы диск не нужен.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Вопрос не в том чтобы кого то ограничить

При этом машина при работе скрипта становится неюзабельной ВООБЩЕ.

Не угадал.

anonymous
()

Кстати, насчёт впихивания невпихуемого: Может стоит взять дополнительный ssd и выделить его только под свопинг? Ну и ограничить контейнер скажем 20гб оперативки. А если нет, то провернуть всё в виртуалке на отдельном диске чтобы свопингом занималась уже виртуалка и не трогала при этом диски системы.

kirill_rrr ★★★★★
()
Ответ на: комментарий от anonymous

У тебя всё i/o всё ещё висит на системном диске и всё ещё ложит всю систему, только оно ещё активней потому что ты требуешь ворочать 40гб данных в ещё меньшем количестве памяти. И всё это разумеется всё ещё в 1 поток.

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

У тебя всё

Ну ты попробуй для начала. А любителей воображаемых глобусов и без тебя здесь хватает.

anonymous
()
Ответ на: комментарий от anonymous

Мой комп живёт в свопинге, я прекрасно знаю о чём говорю. Пусть ТС пробует и потом отписывается что сработает лучше.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Мой комп живёт в свопинге, я прекрасно знаю о чём говорю.

То есть ulatency ты не пробовал, cgroup ты не пробовал, но прекрасно знаешь, о чём говоришь?

anonymous
()
Ответ на: комментарий от anonymous

cgroup я пробовал, и всё было жутко плохо пока я не вырубил к чертям управление памятью через него.

ulatency - костыль. Бегать надо уметь без костылей.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

ulatency - костыль.

Типа не работает? Результат плохой? Работа системы стала хуже? Или вообще ничего не поменялось?

PS: Сбор статистики по работе ПК теперь плохо?

anonymous
()
Ответ на: комментарий от kirill_rrr

в реальном мире всё работает по шрёдингеру. ты не вписался в рыночек

anonymous
()
Ответ на: комментарий от kirill_rrr

Чтобы у человека на той стороне был собеседник

А вы друг друга только по регу отличаете? Вот это всегда поражало. Как можно быть настолько слепыми? Я на реги в принципе не смотрю, различаю тоько по содержанию.

anonymous
()
Ответ на: комментарий от kirill_rrr

А у меня всё было отлично. Так что очевидно, что ты жопорук.

anonymous
()
Ответ на: комментарий от kirill_rrr

Чтобы у человека на той стороне был собеседник

Я кстати предлагал добавить к анонам хэш IP. Но тут же начался базар за коллизии и подбор.

anonymous
()
Ответ на: комментарий от kirill_rrr

команду лингвистов

То есть в данном топе ты сам не способен отличить мои сообщения от сообщений регов и другого анона?

anonymous
()
Ответ на: комментарий от anonymous

В данном топе я не уверен что подключился второй анон. И тем более я не вижу смысла писать в чужом топе анону не по теме через 3-4 дня, когда у меня будут результаты работы ulatency

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Но анон вообще изначально слит

Выкинь свой воображаемый глобус нахрен. Ты о чём, «Вася»?

anonymous
()
Ответ на: комментарий от anonymous

Пролистай вверх, почитай о чём речь шла. Там я заявил (предположительно какому то другому анониму) что мне тупо не с кем будет продолжать разговор про эффективность ulatency.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

anonymous
()
Ответ на: комментарий от kirill_rrr

мне тупо не с кем будет продолжать разговор про эффективность ulatency.

Извините, что вмешиваюсь. Ну так говори тогда сам с собой, лишним не будет, инструмент то (ulatency) достаточно интересный.

anonymous
()
Ответ на: комментарий от anonymous

Чтобы его задействовать, мне надо включить обратно поддержку cgrop_mem и снова потерять 30-40% доступной оперативки.

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

надо включить обратно поддержку cgrop_mem и снова потерять 30-40% доступной оперативки.

А чего ж ты сразу то не сказал об этом? Что ж ты му-му тут понимаешь? Тебе получается не катит, но у ТС то нулевая отзывчивость, ему не до процентов.

anonymous
()

Хотелось бы на скрипт посмотреть. Наверняка грузит весь масштаб вместо небольших порций локального региона.

rec = cur.fetchall()

Ограничивай :D

RedEyedMan666
()
Последнее исправление: RedEyedMan666 (всего исправлений: 2)
Ответ на: комментарий от anonymous

Ну и где там предложение отключить cgrops? Я всего лишь говорил, что недостаточно просто выставить лимит на группу. Нужно ещё что то чтобы разгрузить i/o с системного диска или вообще планировщика свопинга.

kirill_rrr ★★★★★
()

shared_buffers = 7936MB
effective_cache_size = 23808MB
maintenance_work_mem = 1984MB

А мне кажется, или это великовато? Может не надо держать 23 гига кеша в оперативке и ещё всего разного прочего гигов 10?

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 2)
Ответ на: комментарий от kirill_rrr

Ну и где там предложение отключить cgrops? Я всего лишь

К окулисту, родной! Теряешь зрение как минимум.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.