Юзается SWAP при свободной памяти.

По умолчанию, система подключает подкачку (swap) при исчерпании 60% оперативной памяти. Если у вас её много, то значительная часть её будет почти не задействована. Открываем файл:

sudo nano /etc/sysctl.conf

и в конец пишем vm.swappiness = 10

сохраняем и применяем:

sudo sysctl -p

Теперь подкачка будет включаться при исчерпании 90% оперативки.

http://linuxoidblog.blogspot.ru/2015/06/debian-8-jessie.html

Всё же лучше /etc/sysctl.d/

C swappines игрался, сейчас он установлен в 10.

root@web-server:/etc/php/7.0/fpm/pool.d# cat /proc/sys/vm/swappiness
10

Это нормально. Почитай в часности вот тут: https://unix.stackexchange.com/questions/2658/why-use-swap-when-there-is-more...

It is normal for Linux systems to use some swap even if there is still RAM free. The Linux kernel will move to swap memory pages that are very seldom used (e.g., the getty instances when you only use X11, and some other inactive daemon).

Если совсем жаба гложит и спать не даёт, выстави swappines в ноль.

Ахаха. Что это за бред?

vm.swappiness не является процентом. Это значение, устанавливающее приоритет анонимных страниц памяти перед page cache. Если vm.swappiness равен 100, то приоритет их одинаков и kswapd будет с одинаковым усердием сканировать и тот, и другой тип страниц.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/...

Мопед не мой. Cast Sunderland93

Не надо, пожалуйста, бояться swap'а. Постоянно слышу подобную чушь: «боже, жуткий swap тормозит мои сайтики, без него лучше живётся, все страницы должны быть в первичной памяти, аааааа». Вас не сами страницы памяти, размещённые в swap, должны беспокоить, а то, какова активность swap-in'а и swap-out'а. Смотреть следует, через vmstat, значения si и so. Если ядро решило, при vm.swappiness=10, следует переместить несколько страниц в swap, то, поверьте, им там самое место.

Судя по статье (https://en.wikipedia.org/wiki/Swappiness), он и впрямь ошибся. Надо было мне проверять источники.

А это разве проблема? Это как-то сказывается на производительности? Лично я перестал бояться свопа и с тех пор мои волосы стали мягкие и шелковистые.

Меня пугает не производительность свопа, а убитие SSD-шечки.

Вот что юзает своп:

PID=2396 swapped 44 KB (nginx)
PID=2397 swapped 4 KB (nginx)
PID=2399 swapped 20 KB (nginx)
PID=5033 swapped 136 KB (transmission-da)
PID=5918 swapped 112 KB (sshd)
PID=5919 swapped 80 KB (sftp-server)
PID=13065 swapped 2484 KB (mysqld)
PID=24797 swapped 4 KB (sshd)
Overall swap used: 2884 KB

Ладно sshd. Но nginx сцука активно работает. И судя по iotop периодически читает и пишет информацию (логи отключены, сайт на Wordpress с большой посещаемостью, активирован fastcgi cache, который к тому же находится прямиком в /dev/shm). Я напротив хочу чтоб он юзал память, тем более что в иные часы бывает по 60 коннектов в секунду.

А что будет если я нафиг отключу своп-раздел, и создам своп-файл в /dev/shm ?

Сделай (в дополнение к обычному) немного свопа в zram с высоким приоритетем. Ну или в файле в shm

nginx сцука активно работает

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

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

Замечаю что начинается юзаться небольшое количество свопа при огромном количестве доступной памяти.

И это правильно. В своп сбрасывается то, что совсем не используется, чтобы освободить больше места под кэш ФС и дисковые буферы.

Так как статья ориентирована на не слишком труЪ линуксоидов, так сказать - написал чтобы было наиболее понятно.

Арендую сервер у OVH с 3мя SSD, 3й год подряд. Работают Java-монстры, съедающие регулярно под 30 ГиБ (всего стоит 32 ГиБ). swap раздел есть, vm.swappiness=10. Никаких проблем нет.

Рекомендую, всё же, не гнаться за микрооптимизациями, однако, если вы РЕАЛЬНО измерили реальный swap activity, например, настроили sar и посмотрели через день статистику, а потом сравнили это с показаниями S.M.A.R.T. SSD (через smartctl), и проблема реально есть, то используйте zram, штука хорошая.

Исправьте, пожалуйста. Для новичков стоит использовать формулировку, использованную в документации к RHEL 7. Вы же чётко указали совершенно неправильные вычисления.

The swappiness value, ranging from 0 to 100, controls the degree to which the system favors anonymous memory or the page cache. A high value improves file-system performance while aggressively swapping less active processes out of RAM. A low value avoids swapping processes out of memory, which usually decreases latency at the cost of I/O performance. The default value is 60.

WARNING

Setting swappiness==0 will very aggressively avoids swapping out, which increase the risk of OOM killing under strong memory and I/O pressure.

Между тем, чтобы писать понятнее, и тем, чтобы искажать правду в угоду понятности, есть разница.

Например, ребенок спросил: почему трава зеленая? Правильный, но простой ответ: трава питается солнечным светом, потому в ней есть маленькие частицы которые его впитывают, и они зеленые. Неправильный ответ, но он проще: в ней якобы живут маленькие невидимые человечки, которым нравится зеленый цвет и потому они её красят.

Я сам виноват, что не проверил статью в иных источниках, но мне просто в голову не пришло, что кто-то будет сильно искажать факты в угоду «понятности». Как писали выше

Вы же чётко указали совершенно неправильные вычисления.

Ведь из тех слов можно сделать вывод, что если указать vm.swappiness = 20, то подкачка будет включаться при исчерпании 80% памяти.

Меня пугает не производительность свопа, а убитие SSD-шечки.

Санитары! Криокамера протекла, у нас тут ещё один из глубокого прошлого.

Серьёзно, хватит разносить этот бред. Ресурс у SSD ты не выберешь, даже если будешь годами неперставая туда читать/присать.

http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-... (там серия статей)

TL;DR: разные ssd 18 месяцев(!) муражили по самые помидоры без передышки. После 2 петабайтов(!) данных они таки сдались. Прежде чем ты дойдёшь до таких цифр, твои ssd уже просто морально устареют.

2014

На дворе 2017 и с уменьшением техпроцесса уменьшается количество циклов перезаписи во флеш памяти.

Вот тебе свежая ссылочка из 2017 года:

https://3dnews.ru/938764/

Тестирование все еще в процессе, но несколько SSD уже умерло после перезаписи 200Тб.

Хорошо, исправлю

бывает по 60 коннектов в секунду

Вот это труЪ хайлоад.

но несколько SSD уже умерло после перезаписи 200Тб.

Несколько  — это два (из 11 с уже закончившимся ресурсом).

Даже KingDian S280 (240GB) вынес 664TB

Понел, спс.

А покажи вывод slabtop

Вот это труЪ хайлоад.

Ну...Кагбе для сервака на двухьядерном целике, с четырьмя гигами ОЗУ собранного на коленках за 100 баксов - вполне себе хайлоад :)

https://pp.userapi.com/c836720/v836720443/37e23/yyvzTWjVs0o.jpg

Active / Total Objects (% used)    : 439067 / 827767 (53.0%)
 Active / Total Slabs (% used)      : 28839 / 28839 (100.0%)
 Active / Total Caches (% used)     : 73 / 120 (60.8%)
 Active / Total Size (% used)       : 120209.45K / 173004.00K (69.5%)
 Minimum / Average / Maximum Object : 0.01K / 0.21K / 18.50K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
460629 120560  26%    0.10K  11811       39     47244K buffer_head
 92274  80023  86%    0.57K   6591       14     52728K radix_tree_node
 51324  31018  60%    0.19K   2444       21      9776K dentry
 30056  30056 100%    0.12K    884       34      3536K kernfs_node_cache
 24896  22797  91%    0.06K    389       64      1556K kmalloc-64
 18300  13923  76%    1.05K   1220       15     19520K ext4_inode_cache
 16758  16727  99%    0.19K    798       21      3192K kmalloc-192
 16280  16174  99%    0.20K    814       20      3256K vm_area_struct
 16000  12619  78%    0.03K    125      128       500K kmalloc-32
 10812   9135  84%    0.04K    106      102       424K ext4_extent_status
  9534   9446  99%    0.55K    681       14      5448K inode_cache
  8058   8058 100%    0.08K    158       51       632K anon_vma
  6656   6656 100%    0.02K     26      256       104K kmalloc-16
  6240   6197  99%    0.64K    520       12      4160K shmem_inode_cache
  5780   5530  95%    0.05K     68       85       272K ftrace_event_field
  5120   5120 100%    0.01K     10      512        40K kmalloc-8
  4488   4488 100%    0.04K     44      102       176K Acpi-Namespace
  4438   4051  91%    0.27K    317       14      1268K tw_sock_TCP
  4432   3947  89%    0.25K    277       16      1108K kmalloc-256
  4200   4200 100%    0.07K     75       56       300K Acpi-Operand
  3612   2505  69%    0.09K     86       42       344K kmalloc-96
  3104   2931  94%    0.12K     97       32       388K kmalloc-128
  2856   2856 100%    0.14K    102       28       408K btrfs_path
  2272   1921  84%    0.50K    142       16      1136K kmalloc-512
  2048   1625  79%    1.00K    128       16      2048K kmalloc-1024
  2028   1960  96%    0.61K    156       13      1248K proc_inode_cache
  1426   1426 100%    0.09K     31       46       124K trace_event_file
  1092    927  84%    0.62K     91       12       728K sock_inode_cache
  1088    991  91%    4.00K    136        8      4352K kmalloc-4096
  1037    842  81%    1.88K     61       17      1952K TCP
  1024   1024 100%    0.03K      8      128        32K jbd2_revoke_record_s
   896    896 100%    0.06K     14       64        56K ext4_free_data
   784    784 100%    0.07K     14       56        56K ext4_io_end
   750    750 100%    0.16K     30       25       120K sigqueue
   567    483  85%    0.75K     27       21       432K fuse_inode
   528    451  85%    2.00K     33       16      1056K kmalloc-2048
   460    460 100%    0.69K     20       23       320K files_cache
   456    456 100%    0.20K     24       19        96K file_lock_cache
   438    438 100%    0.05K      6       73        24K Acpi-Parse
   408    408 100%    0.12K     12       34        48K jbd2_journal_head
   390    390 100%    2.05K     26       15       832K idr_layer_cache
   374    331  88%    0.36K     17       22       136K blkdev_requests
   351    351 100%    0.10K      9       39        36K blkdev_ioc
   336    192  57%    0.38K     16       21       128K mnt_cache
   300    245  81%    1.06K     20       15       320K signal_cache
   290    253  87%    3.19K     29       10       928K task_struct
   256    256 100%    0.02K      1      256         4K jbd2_revoke_table_s
   240    210  87%    2.06K     16       15       512K sighand_cache
   224    224 100%    0.25K     14       16        56K dquot
   216    180  83%    0.32K     18       12        72K request_sock_TCP
   192    192 100%    0.06K      3       64        12K kmem_cache_node
   180    180 100%    0.32K     15       12        60K taskstats

Всё норм. Slab не течёт. Соответственно кеш на программы не давит. А значит в своп ушли реально никому не нужные данные.

Вот это вряд ли. Такое железо может намного больше.

Не понял, причем здесь я.

Ресурс у SSD ты не выберешь, даже если будешь годами
неперставая туда читать/присать.

В общем-то, от модели сильно зависит. И это - вполне документируемый параметр у некоторых производителей, так что можно прикинуть достаточно точно иногда.

Только учти, что десктоп SSD при несвойственной нагрузке может при 38TB начинать жаловаться на судьбу.

Я тебя понял =) public_html в /dev/shm, и раз в час синкать с диском. И /var/log туда же =)

Странно это все конечно. Swapiness уже два дня как стоит в единицу. По идее своп должен юзаться в крайнем крайнем случае.

Однако: https://pp.userapi.com/c836720/v836720443/37f43/st9Vc1ihlbg.jpg

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

PID=385 swapped 220 KB (systemd-journal)
PID=523 swapped 4 KB (systemd-timesyn)
PID=966 swapped 100 KB (sshd)
PID=974 swapped 1252 KB (snapd)
PID=979 swapped 44 KB (accounts-daemon)
PID=1011 swapped 20 KB (rsyslogd)
PID=1016 swapped 4 KB (dbus-daemon)
PID=5033 swapped 172 KB (transmission-da)
PID=13065 swapped 104452 KB (mysqld)
PID=18700 swapped 164 KB (vesta-nginx)
PID=18701 swapped 144 KB (vesta-nginx)
PID=21756 swapped 1272 KB (php-fpm7.0)
PID=21862 swapped 1252 KB (php-fpm7.0)
PID=25845 swapped 3244 KB (php-fpm7.0)
PID=25912 swapped 952 KB (nginx)
PID=25913 swapped 2892 KB (nginx)
PID=25914 swapped 812 KB (nginx)
PID=25915 swapped 5580 KB (nginx)
PID=25916 swapped 3672 KB (nginx)
PID=25917 swapped 3636 KB (nginx)
PID=25918 swapped 4908 KB (nginx)
PID=25919 swapped 812 KB (nginx)
PID=25920 swapped 2856 KB (nginx)
PID=25921 swapped 1140 KB (nginx)
PID=31727 swapped 8 KB ((sd-pam))
Overall swap used: 139612 KB

Отсюда у меня появились несколько вопросов:

1. Параметр swapiness теперь на использование свопа не влияет от слова вообще ?

2. Если есть корелляция free memory и swap - значит все таки сказки про available memory (ну в том смысле что «память занятая буферами считается формально свободной и может быть использована приложениями при необходимости») - всего лишь сказки ?

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

4. Может быть есть резон поиграться с drop_caches в кроне ? Костыль, но чо поделаешь.

Где можно подробнее почитать о свопе в 2017-м году, желательно на русском языке нах?

Если честно, мне кажется, что у вас есть процессы, которые очень быстро выделяют память, а потом умирают. Это создаёт резкий дефицит реально свободных страниц и kswapd начинает лихорадочно выгружать всё в swap (включая анонимные страницы, т.к. vm.swappiness=1). Попробуйте настроить что-нибудь типа sar или collectl, чтобы в течения дня собрать очень точную статистику по использованию памяти.

Для того, чтобы точно понять, как работает виртуальная память в Linux, вам нужно погрузиться сюда. Уверяю вас, это не попытка кинуть «понты», я сам так себе (никакой) kernel developer. Просто все статьи крайне быстро устаревают из-за безостановочных изменения алгоритмов и интерфейсов в /proc и /sys. К сожалению, разработчики ядра, зачастую, не очень хорошо документируют интерфейсы. Например, /proc/vmstat содержит кучу интересной статистики по использованию виртуальной памяти, однако документации нормальной нет нигде.

Отвечая на ваши вопросы:

1. Параметр влияет на приоритезацию swapout'а page cache и анонимных страниц памяти;
2. Это не сказка, но алгоритм так абсолютно и безусловно работает только при vm.swappiness=0. Даже при vm.swappiness=1 page frame reclaim algorithm (PFRA) может решить сдвинуть страницы памяти в swap.
3. Не все анонимные страницы (страницы памяти, содержащие память процессов, выделенные через syscalls mmap или brk, sbrk) одинаковы хорошо и заслуживают места в физической памяти в виде страниц. В ядре есть два LRU (Least Recently Used) кэша для анонимных страниц: active и inactive. Смотреть в /proc/meminfo. Если PFRA решит, что нужно освобождать анонимные страницы, то он начнёт с самых старых в inactive списке. Которые реально давно не использовались и не нужны. Гораздо лучше освободить место для кэша, iowait во многих случаях гораздо хуже, чем необходимость поднятия в физическую память старых страниц из swap.
4. Резона нет. Есть резон настроить zswap, чтобы между физической память и блоковым устройством появился ещё один in-memory буфер со сжатием.

Почитать здесь и здесь. И попробовать избавиться от ментальности, что swap - это плохо.

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