LINUX.ORG.RU
ФорумAdmin

Swap и принудительная перезагрузка (proxmox)

 , ,


0

1

Вот мистика прям, сервер перезагружается как только «что-то» сваливается в своп больше чем на 2Gb (ссылка на график, просадки - это ребуты). На сервере 32Gb памяти, две вирт. машины KVM построены на использование 28Gb, 4Gb в запасе. Виртуалки работают от имени рута. Раздел свопа 32 Гб. Вот график использования RSS памяти (собирается с помощью ps) http://prntscr.com/ec1f5d

[root@ve2-de ~]# free -m
             total       used       free     shared    buffers     cached
Mem:         31971      31785        186        113          0        139
-/+ buffers/cache:      31646        325
Swap:        31743        208      31535
[root@ve2-de ~]# last reboot
reboot   system boot  4.4.35-2-pve     Wed Feb 22 03:06 - 16:26  (13:19)
reboot   system boot  4.4.35-2-pve     Tue Feb 21 03:02 - 16:26 (1+13:24)
reboot   system boot  4.4.35-2-pve     Tue Feb 21 01:45 - 16:26 (1+14:40)
reboot   system boot  4.4.35-2-pve     Mon Feb 20 05:37 - 16:26 (2+10:48)
reboot   system boot  4.4.35-2-pve     Sat Feb 18 13:22 - 16:26 (4+03:03)
reboot   system boot  4.4.35-2-pve     Thu Feb 16 19:19 - 16:26 (5+21:06)

[root@ve2-de ~]# grep swap /etc/sysctl.conf
vm.swappiness=5

Места для свопа с запасом, на разделе проблем с местом нету. В логе messages на момент креша пусто, только записи уже по факту новой загрузки

[root@ve2-de ~]# cat /var/log/messages | grep "Feb 22 03"
Feb 22 03:07:04 ve2-de rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="2183" x-info="http://www.rsyslog.com"] start
Feb 22 03:07:04 ve2-de kernel: [    0.000000] Initializing cgroup subsys cpuset
Feb 22 03:07:04 ve2-de kernel: [    0.000000] Initializing cgroup subsys cpu
Feb 22 03:07:04 ve2-de kernel: [    0.000000] Initializing cgroup subsys cpuacct
Feb 22 03:07:04 ve2-de kernel: [    0.000000] Linux version 4.4.35-2-pve (root@nora) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Mon Jan 9 10:21:44 CET 2017 ()
Feb 22 03:07:04 ve2-de kernel: [    0.000000] Command line: BOOT_IMAGE=/ROOT/pve-1@/boot/vmlinuz-4.4.35-2-pve root=ZFS=rpool/ROOT/pve-1 ro root=ZFS=rpool/ROOT/pve-1 boot=zfs quiet
Feb 22 03:07:04 ve2-de kernel: [    0.000000] KERNEL supported cpus:
Подскажите плз как можно понять не так кто, как причину, по которой сервер отправляется в ребут ? С железом вроде как проблем нету. Утилитой stress прошелся по цпу, диску, памяти. Часик в перегруженном режиме подержал, всё ок. Апач немного увеличил время ответа, и всё.


Я правильно понял, что на сервере 32GB RAM физически, и работает две VM, одной выделено: 28, другой 4? + На сервере работает zfs?

Если так то...

Для zfs оставляем 8гб + делаем тюнинг для ARC size, + 3 гб хотя бы под сам proxmox,

Итого:

  • Одна машина так и остается с 4гб.
  • Другая: 28-11=17 гб.

Только так. Чудес не бывает. Можно ещё надеяться на ksm, но лучше поступить так.

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

на сервере 32GB RAM физически, и работает две VM, одной выделено: 28, другой 4?

две вирт. машины KVM построены на использование 28Gb, 4Gb в запасе.

Каким местом ты читаешь? 4Gb в запасе. 28ГБ это вирт.рам1 + вирт.рам2

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

Спасибо за подсказки и ссылку на cookbook.eu! Да, две KVM виртуалки, суммарно на 28 гиг. памяти. Могу предположить, что надо дать больше ресурсов на ОС. Но хотелось бы разобраться куда и сколько.

сейчас так

[root@ve2-de ~]# cat /proc/spl/kstat/zfs/arcstats |grep c_
c_min                           4    33554432
c_max                           4    16762472448
arc_no_grow                     4    0
arc_tempreserve                 4    0
arc_loaned_bytes                4    0
arc_prune                       4    0
arc_meta_used                   4    213406136
arc_meta_limit                  4    12571854336
arc_meta_max                    4    316171744
arc_meta_min                    4    16777216
arc_need_free                   4    0
arc_sys_free                    4    523825152
сейчас всё хорошо, свопа 200мбайт

запустил в фоне

while :; do cat /proc/spl/kstat/zfs/arcstats > ~/arcstats.last; sleep 15; done &

после очередного ребута процесс слетит, а файл останется (надеюсь) посмотрю какие параметры там останутся, будут ли аномальные. Сейчас настораживает

xfiles
() автор топика
Ответ на: комментарий от futurama

Каким местом ты читаешь? 4Gb в запасе. 28ГБ это вирт.рам1 + вирт.рам2

Ах, и правда...

Удивило:

[root@ve2-de ~]# free -m
             total       used       free     shared    buffers     cached
Mem:         31971      31785        186        113          0        139

Нету свободной памяти в наличии у ОС. Кеша всего 139 метров. Думаю сожрал все ARC + виртуалки.

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

Ну так я тебе кинул ссылку на тюнинг ARC кеша. Подожми его, это можно сделать в online, насколько я помню (на постоянку не забудь сделать update-initramfs -u, после правки конфига модуля)! Оставь для ОС не менее трех гб (по мимо ОС, proxmox поднимает и веб-сервер, и кучу всего для кластера). И гигов 8 под zfs ARC ужми до 1гб. к примеру.

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

А что VM KVM нельзя выделить RAM в сумме больше, чем есть у хоста?

Утверждать не стану, но... Насколько помню, при запуске VM, откусывается то кол-во ОЗУ, которое было выделено для VM, потом ksm, может вероятно это дело как-то возвращать обратно, но... Если ничего не поменялось, то zfs на linux не охотно отдает ARC память обратно (если она вообще на это способна в linux).

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

В очередной раз zfs съела 33% ресурса.

Оно не то чтоб прямо съела, оно скорее не так хорошо управляет ОЗУ именно в linux варианте. Да чего уж говорить, открываем тот же freenas требования для zfs - там везде пишут, что для корректной работы zfs требуется от 8 гб. памяти.

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

очередной ребут случился сегодня утром на момент ребута аномалии тут:

[root@ve2-de ~]# cat arcstats.last |grep miss
misses                          4    4622239
demand_data_misses              4    3266198
demand_metadata_misses          4    612195
prefetch_data_misses            4    704710
prefetch_metadata_misses        4    39136
mutex_miss                      4    5536
l2_misses                       4    0

сейчас (растут):

[root@ve2-de ~]# cat /proc/spl/kstat/zfs/arcstats | grep miss
misses                          4    421500
demand_data_misses              4    279451
demand_metadata_misses          4    59026
prefetch_data_misses            4    79432
prefetch_metadata_misses        4    3591
mutex_miss                      4    4
l2_misses                       4    0

весь arcstats на момент ребута

6 1 0x01 91 4368 1148276999 102218377619252
name                            type data
hits                            4    20170385
misses                          4    4622239
demand_data_hits                4    19075161
demand_data_misses              4    3266198
demand_metadata_hits            4    888754
demand_metadata_misses          4    612195
prefetch_data_hits              4    145399
prefetch_data_misses            4    704710
prefetch_metadata_hits          4    61071
prefetch_metadata_misses        4    39136
mru_hits                        4    6029958
mru_ghost_hits                  4    631690
mfu_hits                        4    13933958
mfu_ghost_hits                  4    121094
deleted                         4    4107178
mutex_miss                      4    5536
evict_skip                      4    5545882
evict_not_enough                4    72209
evict_l2_cached                 4    0
evict_l2_eligible               4    398831631872
evict_l2_ineligible             4    74756558848
evict_l2_skip                   4    0
hash_elements                   4    125342
hash_elements_max               4    139312
hash_collisions                 4    205674
hash_chains                     4    1869
hash_chain_max                  4    4
p                               4    1212943595
c                               4    4604489860
c_min                           4    33554432
c_max                           4    16762472448
size                            4    4604282808
hdr_size                        4    46769544
data_size                       4    4333135360
metadata_size                   4    182666240
other_size                      4    41711664
anon_size                       4    29582848
anon_evictable_data             4    0
anon_evictable_metadata         4    0
mru_size                        4    1362447360
mru_evictable_data              4    1284541440
mru_evictable_metadata          4    7448576
mru_ghost_size                  4    3106511360
mru_ghost_evictable_data        4    2981834240
mru_ghost_evictable_metadata    4    124677120
mfu_size                        4    3123771392
mfu_evictable_data              4    3016390656
mfu_evictable_metadata          4    9351168
mfu_ghost_size                  4    846745600
mfu_ghost_evictable_data        4    786776064
mfu_ghost_evictable_metadata    4    59871232
l2_hits                         4    0
l2_misses                       4    0
l2_feeds                        4    0
l2_rw_clash                     4    0
l2_read_bytes                   4    0
l2_write_bytes                  4    0
l2_writes_sent                  4    0
l2_writes_done                  4    0
l2_writes_error                 4    0
l2_writes_lock_retry            4    0
l2_evict_lock_retry             4    0
l2_evict_reading                4    0
l2_evict_l1cached               4    0
l2_free_on_write                4    0
l2_cdata_free_on_write          4    0
l2_abort_lowmem                 4    0
l2_cksum_bad                    4    0
l2_io_error                     4    0
l2_size                         4    0
l2_asize                        4    0
l2_hdr_size                     4    0
l2_compress_successes           4    0
l2_compress_zeros               4    0
l2_compress_failures            4    0
memory_throttle_count           4    463
duplicate_buffers               4    0
duplicate_buffers_size          4    0
duplicate_reads                 4    0
memory_direct_count             4    25921
memory_indirect_count           4    243989
arc_no_grow                     4    1
arc_tempreserve                 4    0
arc_loaned_bytes                4    0
arc_prune                       4    0
arc_meta_used                   4    271147448
arc_meta_limit                  4    12571854336
arc_meta_max                    4    316171744
arc_meta_min                    4    16777216
arc_need_free                   4    0
arc_sys_free                    4    523825152

Физ. сервер - http://prntscr.com/ecdes0 (просадка памяти - ребут). На момент ребута одна из виртуалок начала активно юзать своп - http://prntscr.com/ecdgqk

Насколько я понял вариантов два, или убить арккеш до 1Гб, или добавить памяти на сервер чтобы было 8 гб чистых для арк-кеша?

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

Насколько я понял вариантов два, или убить арккеш до 1Гб

Однозначно. Я бы даже уменьшил его в min 256 mb, макс: 512 мб. Если не используешь l2arc, вполне себе поможет. Как по мне: дефолтные настройки arc - грубейшая ошибка proxmox, на форумах периодически поднимаются подобные вопросы, кстати. ARC - хорош для NAS... - Да и то. Спорный вопрос! Если делать ZoL, то там будет кеш самой операционной системы. К чему двойное кеширование? - Ни к чему! ИМХО, ARC на ZoL, нужен только в случае использования l2arc, чтобы настроить его так, чтобы оно мета данные там хранило. Во всех остальных случаях это не разумно отдавать столько ОЗУ в никуда.

Для zfs, в принципе, без относительно ARC нужна ОЗУ. Так что помимо ARC, у тебя должно оставаться для самого proxmox + zfs, гигов 6-8. Докидывать памяти или нет - дело твое. В твоем случае, можно чуть поджать виртуалки, уменьшить arc. - Должно все ок быть. У тебя все равно сейчас до 16гб ОЗУ тратится в фиг пойми куда, хуже ты себе не сделаешь (конечно, до 16 гб, никто zfs не отдаст столько, ибо у тебя виртуалки успевают я думаю раньше себе памяти откусить, но всё же...).

c_max                           4    16762472448

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

Причина одна ZFS on Linux — какашка.

Zvol отлично работают только в одном случае: экспорт по iscsi.

Переконфигури свой проксмокс на обычный lvm, если хочешь спокойно спать по ночам.

А если нужны фичи zfs и нет san — осваивай SmartOS.

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

А если нужны фичи zfs и нет san — осваивай SmartOS.

В свое время не стал трогать SmartOS, так-как решил, что там очень хорошо все с zfs, но... kvm то не нативен выходит...

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

Вполне нативен и отлично работает. Разве только есть ограничение — в качестве дисков для KVM-виртуалок использоваться будут только zvol, никаких файлов-образов.

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

SmartOS is a free and open-source SVR4 hypervisor, based on the UNIX operating system that combines OpenSolaris technology with Linux's KVM virtualization

Как-то не очень нативно выглядит. Не, ну если работает - то годно, конечно. :)

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

ARC круче линуксового VFS-кэша тем, что имеет два списка: LRU (Last Recently Used — последние использованные блоки) и MFU (Most Frequently Used — самые часто используемые блоки), а у VFS, ЕМНИП, используется только LRU.

Беда в том, что из-за нужды использования SPL как слоя совместимости между GPL'нутым ядром и CDDL'нутым модулем ZFS нельзя просто так взять и не использовать для ZFS-томов линуксовый VFS-кэш (как это делают во FreeBSD [поправьте меня, если я не прав]) и получается такое вот дублирование кэша.

На Linux лучше его уменьшать, но не слишком сильно (если RAM позволяет), чтоб иметь хоть какой-то пул MRU-кэша.

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

Вот презентация по поводу того, как ребята из Joyent (бывшие инженеры Sun) реализовывали KVM в SmartOS: https://www.youtube.com/watch?v=cwAfJywzk8o

Видео от 2011 года, с тех пор много чего допилили и доделали. Я начал использовать SmartOS в 2015, тогда проблем уже не было. Гипервизоры, кстати, ребутаются не чаще раза в квартал — когда обновляю Platform Image.

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

Беда в том, что из-за нужды использования SPL как слоя совместимости между GPL'нутым ядром и CDDL'нутым модулем ZFS нельзя просто так взять и не использовать для ZFS-томов линуксовый VFS-кэш

Как-то так... И это расстраивает. :(

На Linux лучше его уменьшать, но не слишком сильно (если RAM позволяет), чтоб иметь хоть какой-то пул MRU-кэша.

Не понятно, почему оно на linux собирается по умолчанию аж с половиной RAM.

Не в курсе, может быть есть крутилки в zfs, чтобы ему сказать: в ARC храни только MRU?

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

В целом - не плохо. Меня ещё остановило то, что: например, вот навернулся у меня CPU в севрере DELL, я малость помурыжился с поддержкой - ибо им стало там всем плохо, от того, что я использую не провославный debian на серверах. - В итоге все же камень поменяли по гарантии. И с тех пор проблем не было ни раза. Если бы я им сказал, что я пользую SmartOS, они 100%, послали бы меня с заменой CPU.

Радует, что ребята из smartos, сразу сказали, что у нас только локальные стораджи (спасибо, об этом не знал особо), ибо сеть - это УГ. Но, насколько я понимаю, HA у них нету. Ну тут надо исходить из того, а насколько собственно оно и надо это HA. proxmox радует гибкостью в этом плане. Хочешь пять виртуалок в сети храни, пять локально.

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

Joyent по поводу HA говорят, что HA нужно пилить на уровне приложения, а не на уровне VM. В некотором смысле это правильно, я считаю.

Вообще, в Proxmox я HA не тыкал и не знаю, что он там умеет и не умеет. У SDC есть поддержка HA для некоторых служб управляющей системы, когда копии контейнеров (SmartOS ещё и зоны-контейнеры умеет) этих служб поднимаются и на вычислительных узлах кластера.

Если бы я им сказал, что я пользую SmartOS, они 100%, послали бы меня с заменой CPU.

Можно сказать, что используешь Solaris — у многих вендоров он числится как поддерживаемая ОС.

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

Не понятно, почему оно на linux собирается по умолчанию аж с половиной RAM.

Почему-то с такими опциями по умолчанию его собирают. Такие опции хороши для NAS, а для нагруженных серверов это не очень.

Не в курсе, может быть есть крутилки в zfs, чтобы ему сказать: в ARC храни только MRU?

Обычно везде пишут только про настройки Prefetch и размер ARC, про настолько тонкую настройку инфу не находил. Можно задать вопрос на GitHub.

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

Использую, только запилили их раньше. Если в ядро не пытаться лазить за чем-то весёлым (вроде сложных правил iptables или сервера OpenVPN), то всё отлично. Ещё есть поддержка Docker. В SDC тыкал — работает, на голой SmartOS не пробовал. Не нашёл для себя плюсов в использовании Docker (конкретно на этом производстве) и остался на контейнерах/зонах и местами KVM.

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

Использую, только запилили их раньше

емнип, их запилили и дропнули надолго, потом вспомнили дето в 14-м и до продакта только в 16-м допилили

Если в ядро не пытаться лазить за чем-то весёлым (вроде сложных правил iptables или сервера OpenVPN), то всё отлично

какое ядро? Lx-зона этож транслятор сисколов (типа фряшного линуксятора)

В SDC тыкал — работает

SDC куплен/собран_из_исходников/или_iso-ник_с_joyent_скачал ?

поделись, сколько оно жрет ресурсов под себя?

anonymous
()

На сервере 32Gb памяти, две вирт. машины

Нахрена там ZFS - вот в чем вопрос.

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

Имею ввиду нищебродскую сеть.

а с чего это 1Гбит стала нищебродской? латенси много ниже чем у бэкэнда из HDD, вот если снизу SSD — то да, надо 10Гбит и выше.

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

тему не читай - сразу отвечай
у ТС в первом посте 4.4.35
у меня, кстати, тоже на 35 были глюки с перезагрузками, обновился, пока хорошо, ТТТ

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

какое ядро? Lx-зона этож транслятор сисколов (типа фряшного линуксятора)

Говорю же, не все моднявые сисколлы работают ещё. Ceph, например, на таком не покрутишь.

SDC куплен/собран_из_исходников/или_iso-ник_с_joyent_скачал ?

Platform Image последней версии с сайта Joyent.

поделись, сколько оно жрет ресурсов под себя?

Собирал кластер точно по документации — один узел (Headnode, HN) зарезервирован под сам SDC, остальные (Compute Node, CN) доступны для VM/контейнеров. Для CN можно задать коэффициент зарезервированной для гипервизора RAM, если ты захочешь что-то покрутить в Global Zone или хочешь, чтобы ARC был не менее стольки-то процентов от RAM узла.

Кластер настроил с использованием VLAN и аггрегированных линков (LACP), всё отлично работает. SDN-fabric тоже работают, но использовать в работе пока не приходилось.

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

> использую не провославный debian

> 100%, послали бы меня с заменой CPU

Вот это поворот! А браузер, шелл и клавиши переключения локали они не оговаривают?

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

Вот это поворот! А браузер, шелл и клавиши переключения локали они не оговаривают?

Легко могут завернуть на чем угодно. Меня спасла лишь доброжелательность обслуживающего персонала, и ошибка на аппаратной консоли сервера - при том ошибка повторялась один раз в 3 суток. - В общем CPU, отработал месяц, и шарахнулся на такую вот голову.

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

Да все они одинаковые +/-. По качеству кстати, тоже. Железо от HP, ломается точно так же как и от DELL. Только DELL - дешевле и разнообразнее. А в сути - все это на Intel держится железе.

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

бери Supermicro готовое или комплекты и собирай сам, выйдет еще дешевле делла.

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

Обновил ядро.

Зажал арк кеш с 16 Гб (дефолт) до 8 Гб.

Добавил 32 Гб памяти, распланировал так, чтобы 8 Гб под арк было свободно в будущем.

Сейчас всё хорошо, вот уже вторые сутки полёт стабильный http://prntscr.com/eelxvj

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

Всем спасибо за помощь!

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

В целом - ОК. Но ИМХО, памяти для ARC, можешь ещё уменьшить (1-2 гб., если не пользуешься L2ARC), не вижу реального смысла от неё для виртуализации.

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

SmartOS только на iSCSI без локальных дисков

Не могут ли уважаемые DALDON или xfiles расказать что и где нужно записать в загрузочной флешке SmartOS, чтобы она при загрузке монтировала iSCSI target со внешнего NAS, создавала на нем zfs и после этого все vm создавала ,бы и хранила бы именно на внешнем NAS при этом сама SMARTOS была бы физически бездисковой (за исключением загрузочной флешки). Такая возможность реализована в proxmox и прекрасно работает даже с NFS шарами.

svlinux
()
Ответ на: SmartOS только на iSCSI без локальных дисков от svlinux

1. Советую почитать мануалы по ZFS. Ни один вменяемый инженер не будет создавать zpool на iscsi — physical disks & physical controllers only (HBA SAS/SATA preferred).

2. Joyent не поддерживает в принципе shared storage. ЕМНИП, в SmartOS iscsi службы отсутствуют вообще.

3. Если очень хочется такой изврат — ставь OmniOS на флэшку и вперёд! Мануал по созданию виртуалок есть у них на сайте.

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