LINUX.ORG.RU

DragonFly BSD и потребление памяти

 , ,


1

1

Сап. Поставил тут на днях (вчера) DragonFlyBSD, ибо на опёнке нет нужных дровишек, да и работает он слегка задумчиво, хотя, конечно, пока он мне больше всех зашёл. Стрекоза очень ничего, мне понравилась, и ФС у них весёлая (которую я пока не поставил, каюсь, юзаю стоковую UFS), и работает шустро, и, что самое главное, относительно свежие железки поддерживает. Словом, была бы сказка, если бы не странное пожирание овер гигабайта ОЗУ. Если есть идеи - подскажите, будьте любезны, куда копать. Скрин с htop прилагается, отсортировал по потреблению памяти. Оно и без иксов так, примерно 980МБ поедает до запуска оных. https://ibb.co/XS0ZLch

P.S. - Кто-нибудь собирал Polybar вне FreeBSD? Если есть какой-то ман или рекомендации, ткните носом.

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

Пул-то уже почти трёхлетней давности, так-то. Топ я кинул, по sysctl могу вот это вот показать:

vm.stats.vm.v_interrupt_free_min: 1221
vm.stats.vm.v_pageout_free_min: 2436
vm.stats.vm.v_cache_max: 87484
vm.stats.vm.v_cache_min: 43742
vm.stats.vm.v_cache_count: 356
vm.stats.vm.v_inactive_count: 6500
vm.stats.vm.v_inactive_target: 436798
vm.stats.vm.v_active_count: 135862
vm.stats.vm.v_wire_count: 321488
vm.stats.vm.v_free_count: 1467811
vm.stats.vm.v_free_min: 9719
vm.stats.vm.v_free_target: 43742
vm.stats.vm.v_free_reserved: 4866
vm.stats.vm.v_page_count: 1932027
vm.stats.vm.v_page_size: 4096
vm.stats.vm.v_kthreadpages: 0
vm.stats.vm.v_rforkpages: 0
vm.stats.vm.v_vforkpages: 21959
vm.stats.vm.v_forkpages: 234749
vm.stats.vm.v_kthreads: 1
vm.stats.vm.v_rforks: 0
vm.stats.vm.v_vforks: 594
vm.stats.vm.v_forks: 1610
vm.stats.vm.v_tfree: 3013492
vm.stats.vm.v_pfree: 819488
vm.stats.vm.v_dfree: 0
vm.stats.vm.v_pdpages: 0
vm.stats.vm.v_ppwakeups: 0
vm.stats.vm.v_pdwakeups: 0
vm.stats.vm.v_reactivated: 2072
vm.stats.vm.v_intrans: 751
vm.stats.vm.v_vnodepgsout: 3122
vm.stats.vm.v_vnodepgsin: 8101
vm.stats.vm.v_vnodeout: 495
vm.stats.vm.v_vnodein: 8101
vm.stats.vm.v_swappgsout: 0
vm.stats.vm.v_swappgsin: 0
vm.stats.vm.v_swapout: 0
vm.stats.vm.v_swapin: 0
vm.stats.vm.v_ozfod: 0
vm.stats.vm.v_zfod: 1600311
vm.stats.vm.v_cow_optim: 0
vm.stats.vm.v_cow_faults: 273668
vm.stats.vm.v_vm_faults: 3432293
vm.stats.sys.v_soft: 180039
vm.stats.sys.v_timer: 1292549
vm.stats.sys.v_ipi: 2109617
vm.stats.sys.v_intr: 3819175
vm.stats.sys.v_syscall: 41728267
vm.stats.sys.v_trap: 255423
vm.stats.sys.v_forwarded_misses: 0
vm.stats.sys.v_forwarded_hits: 0
vm.stats.sys.v_forwarded_ints: 0
vm.stats.sys.v_intrans_wait: 0
vm.stats.sys.v_intrans_coll: 0
vm.stats.sys.v_swtch: 3421630

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

Пул-то уже почти трёхлетней давности, так-то.

Разъясняю: это был пример возможных граблей пингвиноориентированного софта вне пингвина, на которые я натыкался сам (и о которых вспомнил).
Во фре кстати, оно долго не фикшено было — видимо, потому что среди пользователей фри htop не особо популярен. А уж количество пользователей у стрекозы поменьше будет.
Еще оно (вроде бы, гуглить неохота) занятую память не так считало, и этим грешило довольно много разного софта, просто потому что память организована по другому.

по sysctl могу вот это вот показать

Это не то, во фре есть vm.total (подсчитывается раз в пяток секунд ядром):


% sysctl vm.vmtotal
vm.vmtotal: 
System wide totals computed every five seconds: (values in kilobytes)
===============================================
Processes:		(RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 77)
Virtual Memory:		(Total: 4481056K Active: 4464324K)
Real Memory:		(Total: 996316K Active: 994936K)
Shared Virtual Memory:	(Total: 147428K Active: 130988K)
Shared Real Memory:	(Total: 107408K Active: 106192K)
Free Memory:	4649732K
довольно хорошо совпадает с
# ps auxf|awk '{sum+=$6} END {print sum/1024/1024 "ГБ"}'
1,08273ГБ
top показывает:
% top -n 1|grep Mem
Mem: 634M Active, 1020M Inact, 1749M Wired, 766M Buf, 4487M Free
для сравнения поставил htop:
Mem[|||||||||||||||        2.33G/7.78G]

anonymous ()

Работа с памятью в *BSD кардинально отличается от Linux. top может показывать, что Free около ноля. Но при этом много Wired или Laundry. Как только памяти не хватает, сразу же очищаются в порядке приоритета кеши и прочее, которое было заюзано но оставлено на случай если вдруг снова понадобятся. Все сделано для того, чтоб уменьшить, насколько это возможно, фрагментацию и прочие факторы негативно влияющие на производительность. О том, как FreeBSD юзает память можно найти детальное описание в рассылке, вопросов поднималось много. По DragonFly описания я не мог найти. Но думаю, основные принципы не далеко ушли от остальных *BSD.

Так что единственный вариант - смотреть сколько памяти юзается в данный момент (Active в top). Все остальное - тлен.

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

Хм. Вон оно как. Нужно будет подписаться на их рассылку, плюс поэксперементировать с заполнением памяти до конца, чтобы знать, какую реакцию со стороны системы ожидать. С чего мой бугурт начался-то - в OpenBSD у меня 26мб без иксов елось, с ними - около 90мб. Поэтому эти большие циферки со старта меня, мягко говоря, удивили. Спасибо за подробное разъяснение, думаю, жить станет легче)

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

26мб

хм, ну видимо фреймбуфера и нормальных драйверов там не завезли? чем меньше памяти расходуется, тем хуже и медленней работает. ещё можно как в венде — 100500 памяти на различные структуры мониторинга бонусом, причём, большинству пользователей подробная статистика скорее нужна, чем нет.

anonymous ()