Миф об оперативной памяти в linux

Информация об оперативной памяти в Linux « Developer Tales

25Июн/122

Удивителен и неповторим Linux в своем многообразии. Возникла недавно необходимость получить информацию об оперативной памяти и слотах, которые есть в машине под Linux'ом. Как оказалось, все далеко не просто в этом вопросе. Далее будет рассмотрена целая куча вариантов получения информации об оперативной памяти и железу, связанному с RAM.

Первой желаение — выяснить сколько ее, оперативной памяти.

Вводим:

Получаем что-то вроде:

             total       used       free     shared    buffers     cachedMem:       2052516    1703660     348856          0      75256     243296-/+ buffers/cache:    1385108     667408Swap:      2086908     247184    1839724

Собственно, в данном случае, первая строка + первый столбец дают количество оперативной памяти — ~2Gb.

Более удобный вывод того же значения можно получить такой командой:

cat /proc/meminfo | grep MemTotal

Результат — все те же 2Gb:

Теперь хотелось бы понять, сколько слотов установлено, не заглядывая под «капот». Можно сделать так:

sudo lshw -short -C memory | grep MHz | wc -l

Команда выдаст число, равное количеству установленных планок оперативной памяти. Ее смысл заключается в выводе информация о памяти через системную утилиту, поиск вхождения «Mhz» и подсчет количества строк.

Еще есть утилита с графическим интерфейсом под названием hardinfo. Однако, все, что она делает — отображает вывод системных утилит в окне 

На этом не стоит останавливаться. Теперь хотелось бы узнать что-нибудь более конкретное об установленных планках RAM. Тут может помочь dmidecode, которая выводит детальную информацию по различным системным параметрам:

sudo dmidecode —type 17 | more

Увидим что-то вроде такого:

123456789101112131415161718192021222324252627282930313233343536373839 Handle 0x0035, DMI type 17, 28 bytesMemory Device    Array Handle: 0x0033    Error Information Handle: Not Provided    Total Width: 64 bits    Data Width: 64 bits    Size: 1024 MB    Form Factor: DIMM    Set: None    Locator: DIMM0    Bank Locator: BANK0    Type: DDR    Type Detail: Synchronous    Speed: 1333 MHz    Manufacturer: Manufacturer0    Serial Number: SerNum0    Asset Tag: AssetTagNum0    Part Number: PartNum0    Rank: UnknownHandle 0x0037, DMI type 17, 28 bytesMemory Device    Array Handle: 0x0033    Error Information Handle: Not Provided    Total Width: Unknown    Data Width: Unknown    Size: No Module Installed    Form Factor: DIMM    Set: None    Locator: DIMM1    Bank Locator: BANK1    Type: Unknown    Type Detail: Unknown    Speed: Unknown    Manufacturer: Manufacturer1    Serial Number: SerNum1    Asset Tag: AssetTagNum1    Part Number: PartNum1    Rank: Unknown

Тут можно заметить, что пустые слоты тоже отображаются, но в поле Size у них написано «No Module Installed». Этим можно воспользоваться, чтобы выяснить, сколько осталось свободных слотов:

sudo dmidecode —type 17 | grep «No Module Installed» | wc -l

Хочу предупредить, что были реальные ситуации, когда на материнке было всего 2 слота, а Linux показывал еще 2 свободных — это не может не огорчать.

Если нужно просто получить информацию о частоте, то можно сделать так:

sudo dmidecode —type 17 | grep Speed

Самое грустное это то, что dmidecode далеко не всегда корректно распознает тип оперативной памяти и может вместо, например, DDR3 показывать DDR или вообще Unknown.

Конечно, можно открыть крышку и посмотреть на планку RAM, но можно поступить иначе (бывает нужно, когда нельзя вскрывать системный блок).

Можно определить производителя и модель материнской платы и посмотреть, какие типы оперативной памяти поддерживает материнская плата. Делается это той же командой dmidecode:

dmidecode —type baseboard

Получим информацию вида:

12345678910111213141516171819202122232425262728 Handle 0x0002, DMI type 2, 15 bytesBase Board Information    Manufacturer: ASUSTeK Computer INC.    Product Name: P7H55    Version: Rev X.0x    Serial Number: MT7014030601213    Asset Tag: To Be Filled By O.E.M.    Features:        Board is a hosting board        Board is replaceable    Location In Chassis: To Be Filled By O.E.M.    Chassis Handle: 0x0003    Type: Motherboard    Contained Object Handles: 0Handle 0x003E, DMI type 41, 11 bytesOnboard Device    Reference Designation: Onboard Ethernet    Type: Ethernet    Status: Enabled    Type Instance: 0Handle 0x003F, DMI type 41, 11 bytesOnboard Device    Reference Designation: Onboard Audio    Type: Sound    Status: Enabled    Type Instance: 0

Здесь Manufacturer — производитель материнской платы, а Product Name — ее модель. Теперь осталось загуглить модель

P.S. Следует помнить, что все системные команды необходимо выполнять под суперпользователем.

Источник: http://microfork.com/check-ram-linux/

Как узнать количество памяти в Linux, Ubuntu

Как можно узнать количество оперативной памяти (свободной, занятой, всего) в Linux (debian, ubuntu и пр.)?
Вы можете использовать следующие команды в терминале, чтобы выяснить реальный размер RAM под Linux, либо удаленно по ssh для сервера с Linux.

Файл /proc/meminfo

$ less /proc/meminfo

или

$ cat /proc/meminfo

Пример вывода

MemTotal: 512000 kB MemFree: 64728 kB Buffers: 0 kB Cached: 0 kB SwapCached: 0 kB Active: 0 kB Inactive: 0 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 512000 kB LowFree: 64728 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 2080 kB Writeback: 0 kB AnonPages: 0 kB Mapped: 0 kB Slab: 0 kB PageTables: 0 kB NFS_Unstable: 0 kB Bounce: 0 kB CommitLimit: 0 kB Committed_AS: 0 kB VmallocTotal: 0 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 Hugepagesize: 2048 kB

Команда free

Команда free отображает общее количество свободной и занятой физической и своп памяти в системе, а также буферы, используемые ядром:

$ free -m

или

$ free -g

Пример вывода

total used free shared buffers cached Mem: 500 436 63 0 0 0 -/+ buffers/cache: 436 63 Swap: 0 0 0

Опции

Из мануала:

The -b switch displays the amount of memory in bytes; the -k switch (set by default) displays it in kilobytes; the -m switch displays it in megabytes. The -t switch displays a line containing the totals. The -o switch disables the display of a «buffer adjusted» line. If the -o option is not specified, free subtracts buffer memory from the used memory and adds it to the free memory reported. The -s switch activates continuous polling delay seconds apart. You may actually specify any floating point number for delay, usleep(3) is used for microsecond resolution delay times.

Команда vmstat

Комманда vmstat показывает статистику памяти включая дополнительную информацию о процессах

$ vmstat -s

Пример вывода:

512000 K total memory 448132 K used memory 0 K active memory 0 K inactive memory 63868 K free memory 0 K buffer memory 0 K swap cache 0 K total swap 0 K used swap 0 K free swap 16956820 non-nice user cpu ticks 3531 nice user cpu ticks 3533257 system cpu ticks 459840831 idle cpu ticks 141559 IO-wait cpu ticks 0 IRQ cpu ticks 0 softirq cpu ticks 0 stolen cpu ticks 1424740 pages paged in 37143676 pages paged out 0 pages swapped in 0 pages swapped out 0 interrupts 1889466486 CPU context switches 1373407048 boot time 490111497 forks

Команда top

Эту команду я люблю больше всего, за ее реалтаймовость. Показывает в настоящем времени общую информацию о памяти, загруженности процессора и процессах которые выполняются

$ top

Пример вывода:

03:22:24 up 56 days, 2:24, 1 user, load average: 1.49, 1.29, 1.28 Mem: 512000k total, 448372k used, 63628k free, 0k buffers Swap: 0k total, 0k used, 0k free, 0k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1628 mysql 15 0 265m 56m 7824 S 14.3 11.3 789:48.32 mysqld 26074 usamotor 15 0 193m 49m 7488 S 11.3 9.9 12:15.55 php 13721 usamotor 15 0 191m 45m 7472 R 7.3 9.1 2:18.71 php 1 root 15 0 8364 848 724 S 0.0 0.2 1:04.34 init 1397 root 15 0 63312 1996 1284 S 0.0 0.4 0:12.50 nmbd 1401 root 15 0 93348 3488 2516 S 0.0 0.7 0:05.01 smbd 1420 root 18 0 93480 1684 608 S 0.0 0.3 0:00.00 smbd 1421 root 23 0 54572 992 500 S 0.0 0.2 0:00.00 saslauthd 1422 root 23 0 54572 648 156 S 0.0 0.1 0:00.00 saslauthd 1429 root 15 0 5988 732 572 S 0.0 0.1 0:37.04 syslogd 1436 daemon 18 0 18720 440 284 S 0.0 0.1 0:00.00 atd 1444 bind 25 0 121m 11m 2388 S 0.0 2.3 0:00.55 named 1458 root 15 0 220m 13m 7616 S 0.0 2.7 2:14.62 apache2 1519 root 25 0 9144 1396 1136 S 0.0 0.3 0:00.00 mysqld_safe 1629 root 25 0 3860 664 568 S 0.0 0.1 0:00.00 logger 1680 root 18 0 21244 924 656 S 0.0 0.2 0:01.17 dovecot 1681 dovecot 15 0 12908 1148 876 S 0.0 0.2 0:00.52 anvil 1682 root 15 0 12908 1196 904 S 0.0 0.2 0:00.41 log 1766 root 15 0 72972 3156 1464 S 0.0 0.6 1:38.07 sendmail-mta 1783 root 15 0 49184 1168 620 S 0.0 0.2 0:27.42 sshd 1791 root 18 0 19340 984 780 S 0.0 0.2 0:00.00 xinetd 1806 root 16 0 33288 2036 1044 S 0.0 0.4 0:00.01 nginx 3209 root 19 0 20916 1016 772 S 0.0 0.2 0:16.68 cron 7983 proftpd 15 0 190m 2000 672 S 0.0 0.4 0:02.39 proftpd 8183 root 15 0 78980 3468 2748 S 0.0 0.7 0:00.01 sshd 9221 usamotor 15 0 78980 1728 988 R 0.0 0.3 0:00.22 sshd 9222 usamotor 15 0 121m 2164 1640 S 0.0 0.4 0:00.02 bash 11507 root 15 0 178m 13m 7812 S 0.0 2.6 0:50.33 ispmgr 13717 root 18 0 36740 3352 2816 S 0.0 0.7 0:00.00 cronrun 13719 usamotor 18 0 46056 1500 1196 S 0.0 0.3 0:00.00 su 13720 usamotor 20 0 9084 1240 1044 S 0.0 0.2 0:00.00 sh 15366 root 15 0 41956 1256 932 S 0.0 0.2 0:00.00 cron 15367 root 15 0 9068 1220 1036 S 0.0 0.2 0:00.00 sh 15368 root 20 0 9068 640 452 S 0.0 0.1 0:00.00 sh 15369 root 16 0 3860 596 496 S 0.0 0.1 0:00.00 run-parts 15381 root 18 0 9072 1256 1072 S 0.0 0.2 0:00.00 logrotate 15382 root 18 0 3876 508 432 S 0.0 0.1 0:00.00 sleep 16095 root 15 0 41956 1256 932 S 0.0 0.2 0:00.00 cron 16096 root 15 0 9068 1236 1056 S 0.0 0.2 0:00.00 sh 16097 root 15 0 3860 592 492 S 0.0 0.1 0:00.00 run-parts

UPD от 19.11.2015

Для того чтоб посмотреть сколько используется памяти сейчас использую htop. Который нужно предаврительно установить командой

apt-get install htop

Пример вывода:

Источник: https://la2ha.ru/dev-seo-diy/unix/linux_ram

Как получить информацию об оперативной памяти в Linux

Продолжая линию предыдущей заметки, сегодня вашему вниманию предлагаю консольный способ получения информации об ОЗУ в Linux.

Получение информации об использовании памяти

Думаю, всем известна программа free, но на всякий случай, для тех, кто ещё не в курсе. При помощи команды free можно получить информацию об используемой/свободной памяти в вашей системе, в том числе и swap:

             total       used       free     shared    buffers     cachedMem:       2062064    1493344     568720          0      82672     526624-/+ buffers/cache:     884048    1178016Swap:      1951740      59396    1892344

Или же более человечный вариант вывода:

             total       used       free     shared    buffers     cachedMem:          2013       1669        343          0         86        624-/+ buffers/cache:        959       1053

Ну и конечно же, стоит упомянуть традиционные top и htop:

Получение информации об аппаратной части

Если вам необходимо получить информацию об установленных платах, не открывая корпус компьютера, можно воспользоваться утилитой dmidecode, предназначенной для извлечения различного рода данных об установленном железе. Чтобы получить данные об установленной памяти, необходимо попросить dmidecode вывести информацию только 17 типа DMI:

Handle 0x002D, DMI type 17, 27 bytes    Error Information Handle: Not Provided    Manufacturer: Manufacturer0Handle 0x002F, DMI type 17, 27 bytes    Error Information Handle: Not Provided    Manufacturer: Manufacturer1

Информацию о контроллере памяти можно получить, указав типы DMI 5 и 6:

Handle 0x0008, DMI type 5, 24 bytesMemory Controller Information    Error Detecting Method: 64-bit ECC    Error Correcting Capabilities:    Supported Interleave: One-way Interleave    Current Interleave: One-way Interleave    Maximum Memory Module Size: 1024 MB    Maximum Total Memory Size: 4096 MB    Memory Module Voltage: 3.3 V    Associated Memory Slots: 4    Enabled Error Correcting Capabilities:Handle 0x0009, DMI type 6, 12 bytesMemory Module Information    Socket Designation: DIMM0    Installed Size: 1024 MB (Single-bank Connection)    Enabled Size: 1024 MB (Single-bank Connection)Handle 0x000A, DMI type 6, 12 bytesMemory Module Information    Socket Designation: DIMM1    Installed Size: 1024 MB (Single-bank Connection)    Enabled Size: 1024 MB (Single-bank Connection)

А указав тип DMI 16, можно получить краткую информацию о пределах возможностей подсистемы управления памятью, установленной на материнской плате:

Handle 0x002B, DMI type 16, 15 bytes    Location: System Board Or Motherboard    Error Correction Type: None    Error Information Handle: Not Provided

Источник: http://ashep.org/2012/kak-poluchit-informaciyu-ob-operativnoj-pamyati-v-linux/

5 команд для проверки использования памяти на Linux

В Linux почти все команды без графического интерфейса. При работе на серверах доступа только оболочка. Итак, сегодня мы покажем команды, которые могут быть использованы для проверки использования памяти в системе Linux. Память включает в себя оперативную память и подкачку.

Часто важно проверить использование общей памяти и памяти, используемой в процессе на серверах, а так же неиспользуемые ресурсы. Если вы работаете на веб-сервере, то сервер должен иметь достаточно памяти, чтобы обслуживать посетителей сайта.

Если такого не будет, то сайт станет очень медленным или даже стать недоступным, когда будет всплеск трафика, просто потому, что памяти будет не хватать. Тоже самое, как и то, что происходит на настольном компьютере.

1. Команда free

Команда free является самой простой и легкой в использовании командой, чтобы проверить использование памяти на Linux. Вот краткий пример

$ free -m total used free shared buffers cached
Mem: 7976 6459 1517 0 865 2248
-/+ buffers/cache: 3344 4631
Swap: 1951 0 1951

Опция -m отображает все данные в мегабайтах. Общий общий объем оперативной памяти ОС Linux 7976 МБ, установленной в системе, то есть 8 Гб.

Колонка used показывает объем оперативной памяти, которая может быть использована на Linux, в нашем случае составит около 6,4 Гб. Загвоздкой здесь является  колонки cached и buffers. Вторая строка говорит, что 4,6 Гб свободно.

Это свободная память в первой строке с добавлением буферов и объема памяти кэша.

Linux имеет привычку кэшировать для повышения производительности, так что память может быть освобождена и использована при необходимости.
Последняя строка, это подкачка памяти (swap), который в этом случае полностью свободна.

2. /proc/meminfo

Следующий способ проверить использование памяти, прочитать файл /proc/meminfo. Знайте, что файловая система /proc не содержит реальных файлов. Они являются виртуальными файлами, которые содержат динамическую информацию о ядре и системы.

Читайте также:  Обзор ubuntu телефонов или ubuntu phones.

$ cat /proc/meminfo
MemTotal: 8167848 kB
MemFree: 1409696 kB
Buffers: 961452 kB
Cached: 2347236 kB
SwapCached: 0 kB
Active: 3124752 kB
Inactive: 2781308 kB
Active(anon): 2603376 kB
Inactive(anon): 309056 kB
Active(file): 521376 kB
Inactive(file): 2472252 kB
Unevictable: 5864 kB
Mlocked: 5880 kB
SwapTotal: 1998844 kB
SwapFree: 1998844 kB
Dirty: 7180 kB
Writeback: 0 kB
AnonPages: 2603272 kB
Mapped: 788380 kB
Shmem: 311596 kB
Slab: 200468 kB
SReclaimable: 151760 kB
SUnreclaim: 48708 kB
KernelStack: 6488 kB
PageTables: 78592 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6082768 kB
Committed_AS: 9397536 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 420204 kB
VmallocChunk: 34359311104 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 62464 kB
DirectMap2M: 8316928 kB

Проверьте значения MemTotal, MemFree, Buffers, Cached, SwapTotal и SwapFree. Они указывают на одни и те же значения, использования памяти в команде free.

3. vmstat

Команда vmstat с опцией -s, показывает статистику использования памяти почти как команда Proc. Вот пример

$ vmstat -s 8167848 K total memory 7449376 K used memory 3423872 K active memory 3140312 K inactive memory 718472 K free memory 1154464 K buffer memory 2422876 K swap cache 1998844 K total swap 0 K used swap 1998844 K free swap 392650 non-nice user cpu ticks 8073 nice user cpu ticks 83959 system cpu ticks 10448341 idle cpu ticks 91904 IO-wait cpu ticks 0 IRQ cpu ticks 2189 softirq cpu ticks 0 stolen cpu ticks 2042603 pages paged in 2614057 pages paged out 0 pages swapped in 0 pages swapped out 42301605 interrupts 94581566 CPU context switches 1382755972 boot time 8567 forks

Верхние несколько строк указывают общий объем памяти, объем свободной памяти и т.д., и так далее.

4. команда top

Команда top обычно используется для проверки памяти и процессора для каждого процесса. Тем не менее она также сообщает общее использование памяти и может быть использована для контроля общего использования памяти. Вывод результата имеет необходимую информацию. Вот пример вывода

top — 15:20:30 up 6:57, 5 users, load average: 0.64, 0.44, 0.33
Tasks: 265 total, 1 running, 263 sleeping, 0 stopped, 1 zombie
%Cpu(s): 7.8 us, 2.4 sy, 0.0 ni, 88.9 id, 0.9 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem: 8167848 total, 6642360 used, 1525488 free, 1026876 buffers
KiB Swap: 1998844 total, 0 used, 1998844 free, 2138148 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2986 enlighte 20 0 584m 42m 26m S 14.3 0.5 0:44.27 yakuake 1305 root 20 0 448m 68m 39m S 5.0 0.9 3:33.98 Xorg 7701 enlighte 20 0 424m 17m 10m S 4.0 0.2 0:00.12 kio_thumbnail

Проверьте KiB Mem и KiB Swap в заголовке. Они указывают на общую, используемую и свободную объем памяти. Информация буфера и кэша присутствует здесь тоже, как и команды free.

5. Команда htop

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

Заголовок в верхней части показывает использование центрального процессора вместе с оперативной памятью и использование своп с соответствующими цифрами.

Информация памяти (RAM)

Чтобы узнать аппаратную информацию об установленной оперативной памяти, используйте команду demidecode. Команда выводит детальную информацию об установленной оперативной памяти.

$ sudo dmidecode -t 17
# dmidecode 2.11
SMBIOS 2.4 present. Handle 0x0015, DMI type 17, 27 bytes
Memory Device Array Handle: 0x0014 Error Information Handle: Not Provided Total Width: 64 bits Data Width: 64 bits Size: 2048 MB Form Factor: DIMM Set: None Locator: J1MY Bank Locator: CHAN A DIMM 0 Type: DDR2 Type Detail: Synchronous Speed: 667 MHz Manufacturer: 0xFF00000000000000 Serial Number: 0xFFFFFFFF Asset Tag: Unknown Part Number: 0x524D32474235383443412D36344643FFFFFF

Информация включает в себя размер (2048MB), тип (DDR2), скорость (667 МГц) и т.д.

Резюме

Все вышеперечисленные команды работают с терминала и не имеют графического интерфейса. При работе на рабочем столе с графическим интерфейсом, гораздо проще в использовании графический инструмент с графическим выводом.

Наиболее распространенные инструменты gnome-system-monitor в gnome и
KSysguard в KDE.

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

Источник: https://andreyex.ru/operacionnaya-sistema-linux/5-komand-dlya-proverki-ispolzovaniya-pamyati-na-linux/

Что стоит знать о памяти в Linux?

Подсистема работы с оперативной памятью в Linux — достаточно многогранная конструкция. Чтобы разобраться в её деталях нужно целенаправленно погрузиться в тему, с обязательным чтением исходников ядра, но это нужно не каждому.

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

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

Какая бывает память?

Физическая и виртуальная

Начнем издалека. В спецификации любого компьютера и в частности сервера непременно числится надпись «N гигабайт оперативной памяти» — именно столько в его распоряжении находится физической памяти.

Задача распределения доступных ресурсов между исполняемым программным обеспечением, в том числе и физической памяти, лежит на плечах операционной системы, в нашем случае Linux.

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

Это избавляет их от необходимости знать друг о друге, размере доступной физической памяти и текущей её занятости. Адреса в виртуальном пространстве процессов называют логическими.

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

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

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

В отличии от других операционных систем, в Linux она практически не используется — логический адрес всегда совпадает с линейным (адресом внутри сегмента, которые сконфигурированы фиксированным образом).

Файловая и анонимная

У приложений существует много способов выделить себе память для тех или иных нужд.

Высокоуровневые языки программирования и библиотеки часто прячут от разработчиков какой из них в реальности использовался и другие детали (хотя их всегда можно «раскусить» с помощью strace).

Если углубляться в особенности каждого доступного варианта, эта статья быстро бы превратилась в книгу. Вместо этого предлагаю разделить их на две, на мой взгляд, крайне важные группы по тому, какую память они выделяют:

  • Файловой памяти однозначно соответствует какой-либо файл или его часть в файловой системе. Первым делом в ней как правило находится исполняемый код самой программы. Для прикладных задач можно запросить отображение файла в виртуальное адресное пространство процесса с помощью системного вызова mmap — после чего с ним можно работать как с любой другой областью памяти без явного чтения/записи, что будет при этом происходить с данными в файловой системе и что будут видеть другие процессы «отобразившие» этот же файл зависит от настроек.
  • Любую другую выделенную память называют анонимной, так как ей не соответствует никакой файл, которые как известно именованы. Сюда попадают как переменные на стеке, так и области, выделенные с помощью функций вроде malloc (к слову, за сценой для выделения больших блоков памяти они обычно тоже используют mmap с особым набором настроек, а для всего остального — brk/sbrk или выдают ранее освобожденную память).

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

Вытесняемая и нет

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

Это означает, что операционная система может откладывать не используемые в данный момент данные из оперативной памяти на жесткий диск («вытесняя»» их из памяти), а затем при попытке к этим данным обратиться — скопировать обратно в физическую оперативную память.

Этот механизм официально называется major page fault, но под просто page fault как правило подразумевают тоже её, так как minor page fault мало кого заботит (отличие в том, что в случае minor ядру удается найти запрашиваемые данные уже загруженными в память с какой-то другой целью и обращения к диску в итоге не происходит).

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

  • Прочитать 4Кб данных с обычного серверного жесткого диска 7200rpm занимает порядка 10 мс, при хорошем стечении обстоятельств чуть меньше.
    • Если вытесненных страниц оказывается много, запросто могут набегать заметные доли секунды (как условным пользователям, так и на внутренних приборах, в зависимости от задачи).
    • Особенно опасны циклические pagefaults, когда есть две или более регулярно используемые области памяти, которые вместе не помещаются в физическую память, по-этому бесконечно вытесняют друг друга туда-обратно.
    • При этом диск вынужден делать честный seek, что само по себе тоже может быть не кстати. Например, если с этим же диском работает какая-либо база данных.
  • Если используется SSD, то ситуация несколько более радужная — из-за отсутствия механического движения аналогичная операция занимает примерно на порядок меньше, около 1 мс или её доли, в зависимости от типа и конкретной модели диска. Но годы идут, а SSD так и остаются нишевым компромиссным продуктом по цене-объему.
  • А теперь для сравнения: если бы страница уже была в памяти, то при обращении к ней счет шел бы на сотни наносекунд. Это почти на 4 порядка быстрее, чем pagefault, даже на SSD.

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

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

Методы управления подсистемой памяти

swap

С файловой памятью всё просто: если данные в ней не менялись, то для её вытеснения делать особо ничего не нужно — просто перетираешь, а затем всегда можно восстановить из файловой системы.

С анонимной памятью такой трюк не работает: ей не соответствует никакой файл, по-этому чтобы данные не пропали безвозвратно, их нужно положить куда-то ещё. Для этого можно использовать так называемый «swap» раздел или файл. Можно, но на практике не нужно. Если swap выключен, то анонимная память становится невытесняемой, что делает время обращения к ней предсказуемым.

Может показаться минусом выключенного swap, что, например, если у приложения утекает память, то оно будет гарантированно зря держать физическую память (утекшая не сможет быть вытеснена). Но на подобные вещи скорее стоит смотреть с той точки зрения, что это наоборот поможет раньше обнаружить и устранить ошибку.

mlock

По-умолчанию вся файловая память является вытесняемой, но ядро Linux предоставляет возможность запрещать её вытеснение с точностью не только до файлов, но и до страниц внутри файла.

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

Несколько примеров, когда это может быть целесообразно:

  • У приложения большой исполняемый файл с большим количеством ветвлений, некоторые из которых срабатывают редко, но регулярно. Такого стоит избегать и по другим причинам, но если иначе никак, то чтобы не ждать лишнего на этих редких ветках кода — можно запретить им вытесняться.
  • Индексы в базах данных часто физически представляют собой именно файл, с которым работают через mmap, а mlock нужен чтобы минимизировать задержки и число операций ввода-вывода на и без того нагруженном диске(-ах).
  • Приложение использует какой-то статический словарь, например с соответствием подсетей IP-адресов и стран, к которым они относятся. Вдвойне актуально, если на одном сервере запущено несколько процессов, работающих с этим словарем.

OOM killer

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

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

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

Если отключить OOM killer полностью, то системе в случае полного дефицита ничего не останется, как перезагрузиться.

Читайте также:  Выпущена новая версия qbittorrent

cgroups

По-умолчанию все пользовательские процессы наравне претендуют на почти всю физически доступную память в рамках одного сервера. Это поведение редко является приемлемым.

Даже если сервер условно-однозадачный, например только отдает статические файлы по HTTP с помощью nginx, всегда есть какие-то служебные процессы вроде syslog или какой-то временной команды, запущенной человеком.

Если же на сервере одновременно работает несколько production процессов, например, популярный вариант — подсадить к веб-серверу memcached, крайне желательно, чтобы они не могли начать «воевать» друг с другом за память в случае её дефицита.

Для изоляции важных процессов в современных ядрах существует механизм cgroups, c его помощью можно разделить процессы на логические группы и статически сконфигурировать для каждой из групп сколько физической памяти может быть ей выделено. После чего для каждой группы создается своя почти независимая подсистема памяти, со своим отслеживанием вытеснения, OOM killer и прочими радостями.

Механизм cgroups намного обширнее, чем просто контроль за потреблением памяти, с его помощью можно распределять вычислительные ресурсы, «прибивать» группы к ядрам процессора, ограничивать ввод-вывод и многое другое. Сами группы могут быть организованы в иерархию и вообще на основе cgroups работают многие системы «легкой» виртуализации и нынче модные Docker-контейнеры.

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

NUMA

В многопроцессорных системах не вся память одинакова. Если на материнской плате предусмотрено N процессоров (например, 2 или 4), то как правило все слоты для оперативной памяти физически разделены на N групп так, что каждая из них располагается ближе к соответствующему ей процессору — такую схему называют NUMA.

Таким образом, каждый процессор может обращаться к определенной 1/N части физической памяти быстрее (примерно раза в полтора), чем к оставшимся (N-1)/N.

Ядро Linux самостоятельно умеет это всё определять и по-умолчанию достаточно разумным образом учитывать при планировании выполнения процессоров и выделении им памяти. Посмотреть как это все выглядит и подкорректировать можно с помощью утилиты numactl и ряда доступных системных вызовов, в частности get_mempolicy/set_mempolicy.

Операции с памятью

Есть несколько тем, с которыми в реальности сталкиваются лишь C/C++ разработчики низкоуровневых систем, и не мне им про это рассказывать. Но даже если напрямую с этим не сталкиваться на мой взгляд полезно в общих чертах знать, какие бывают нюансы:

  • Операции, работающие с памятью:
    • В большинстве своем не атомарны (то есть другой поток может их «увидеть» на полпути), без явной синхронизации атомарность возможна только для блоков памяти не больше указателя (т.е. как правило 64 бита) и то при определенных условиях.
    • В реальности происходят далеко не всегда в том порядке, в котором они написаны в исходном коде программы: процессоры и компиляторы на правах оптимизации могут менять их порядок, как считают нужным. В случае многопоточных программ эти оптимизации часто могут приводить к нарушению логики их работы. Для предотвращения подобных ошибок разработчики могут использовать специальные инструменты, в частности барьеры памяти — инструкции, которые запрещают переносить операции с памятью между частями программы до неё и после.
  • Новые процессы создаются с помощью системного вызова fork, который порождает копию текущего процесса (чтобы запустить другую программу в новом процессе существует отдельное семейство системных вызовов — exec), у которого виртуальное пространство практически полностью идентично родительскому, что не потребляет дополнительной физической памяти до тех пор, пока тот или другой не начнут его изменять. Этот механизм называется copy on write и на нем можно играть для создания большого числа однотипных независимых процессов (например, обрабатывающих какие-то запросы), с минимумом дополнительных расходов физической памяти — в некоторых случаях так жить удобнее, чем с многопоточным приложением.
  • Между процессором и оперативной памятью находится несколько уровней кешей, обращение к которым ещё на порядки быстрее, чем к оперативной памяти. К самому быстрому — доли наносекунд, к самому медленному единицы наносекунд. На особенностях их работы можно делать микро оптимизации, но из высокоуровневых языков программирования до них толком не добраться.

Итого

Подсистему памяти в Linux нельзя бросать на произвол судьбы. Как минимум, стоит следить за следующими показателями и вывести на приборы (как суммарно, так и по процессам или их группам):

  • Скорость возникновения major page faults;
  • Срабатывания OOM killer;
  • Текущий объем использования физической памяти (это число обычно называют RSS, не путать с одноименным форматом для публикации текстового контента).

В штатном режиме все три показателя должны быть стабильны (а первые два — близки к нулю). Всплески или плавный рост стоит рассматривать как аномалию, в причинах которой стоит разобраться. Какими методами — надеюсь я показал достаточно направлений, куда можно по-копать.

Источник: https://www.insight-it.ru/linux/2015/chto-stoit-znat-o-pamiati-v-linux/

Нехватка оперативной памяти в Linux на рабочем ПК: оптимизация и действия при зависании

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

Типична такая ситуация: есть своп (swap, раздел подкачки), который начинает использоваться при нехватке оперативной памяти, и размещен он на HDD, то есть жестком диске с низкой скоростью чтения информации.

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

Почему? Потому что планировщик ядра Linux не может выполнить запрос на какое-то действие в запущенной программе, пока не получит доступ к ее оперативной памяти, выполнить следующее действие тоже не может, образовывается очередь из запросов на чтение с диска, и система «подвисает» именно потому, что обработка очереди происходит гораздо медленнее, чем этого хочет пользователь.

Если в такой момент запустить htop или uptime, то показатель Load Average (LA) будет очень высоким, несмотря на низкую загруженность ядер процессора. Сочетание высокого Load Average и низкой загрузки процессора говорят о забитой очереди процессора.

Часто в интернете советуют изменить параметр ядра Linux vm.swappiness. Узнать его текущее значение на вашей системе можно так:

sysctl vm.swappiness

Ответ будет 60 почти наверняка. Это значит, что ядро Linux начинает свопить редко используемые страницы оперативной памяти, когда использование свободной оперативной памяти достигает 100%-60%=40%.

Часто встречаются рекомендации поставить, например, vm.swappiness=10, чтобы своп не начинал использоваться, пока загрузка ОЗу не достигнет 90%. На самом деле не нужно трогать vm.

swappiness, вы не умнее разработчиков ядра Linux, которые не просто так поставили 60 по умолчанию. Почему?

Представьте, что у вас всего 4 ГБ оперативной памяти, из них прямо сейчас занято 3 ГБ, vm.swappiness=10, своп на жестком диске (HDD) занят на 0%, и вы открываете тяжелый сайт в браузере, для чего требуется больше, чем имеющийся свободный 1 ГБ, например, 2 ГБ.

Операционная система начинает в экстренном порядке отправлять в своп как минимум 0.5 ГБ (а по факту больше), чтобы можно было выделить браузеру необходимое количество оперативной памяти.

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

Проходит 5 минут, и система развисает, потому что окончила процедуру 100% загрузки очереди доступа к медленному жесткому диску, на котором размещена оперативная память (своп). При дефолтном vm.swappiness=60 редко используемые страницы памяти сбрасываются в своп заблаговременно, и резкого зависания на 5-10 минут не происходит.

zram и приоритеты свопов

Рекомендую включить zram — прозрачное сжатие содержимого оперативной памяти. В Ubuntu это автоматизировано, достаточно установить пакет:

sudo apt install zram-config

Здесь и далее для дистрибутивов Rosa, Fedora все то же самое, но вместо zram-config —

zram-start.

Сервис systemd zram-config на Ubuntu будет автоматически добавлен в автозагрузку при установке пакета и запущен при перезагрузке системы. Для запуска вручную:

sudo systemctl start zram-config

остановки:

sudo systemctl stop zram-config

Удаления из автозапуска:

sudo systemctl disable zram-config

Добавление в автозапуск:

sudo systemctl enable zram-config

При запуске zram-config берет число, равное 50% всего объема оперативной памяти, далее делает по одному виртуальному устройству /dev/zramN, где N начинается с 0, для каждого ядра процессора, а объем каждого /dev/zramN равен 50% всей оперативной памяти, деленному на количество ядер процессора.

Так делалается для распараллеливания сжатия содержимого оперативной памяти по ядрам процессора; насколько я знаю, на современных ядрах Linux достаточно одного устройства /dev/zramN, а распараллелится оно само, но меня полностью устраивает искоробочная работа zram-config, и предпочитаю не лезть в нее руками.

Команда swapon -s выведет список всех задействованных свопов с указанием их приоритета. Первым используется тот своп, у которого приоритет выше. Если у вас уже есть дисковый своп и включен zram, то в случае с описанным выше пакетом-автокофигуратором приоритеты из коробки будут правильными.

Например, у дискового свопа будет -1, а все /dev/zramN — 5. Таким образом, сначала используется zram, и только потом — диск.

Кстати, zram часто применяется на смартфонах, какую-либо на глаз заметную нагрузку на процессор при дефолтном методе сжатия lz4 он не создает.

Также приоритет свопа можно указать в /etc/fstab. Покажу на примере, как это сделано на моем рабочем компьютере с 6 ГБ ОЗУ.

$ cat /etc/fstab | grep swap
# swap на SSD
UUID=844fc9fb-509d-4dab-9ea5-a3d5142f76d8 none swap sw,pri=2 0 0
# swap на HDD для гибернации
UUID=b643c42a-0abd-4f35-8865-7a51be5769e8 none swap sw,pri=1 0 0

Опцией монтирования pri=X заданы приоритеты свопов. Если еще включить zram, то картинка будет такой:$ swapon -s
Filename Type Size Used Priority
/dev/sdb3 partition 1005564 0 2
/dev/sda2 partition 6655996 0 1
/dev/zram0 partition 690764 0 5
/dev/zram1 partition 690764 0 5
/dev/zram2 partition 690764 0 5
/dev/zram3 partition 690764 0 5
В первую очередь будет свопиться в zram, то есть сжиматься внутри оперативной памяти без использования внешнего устройства для свопа, во вторую — использовать небольшой своп на SSD. Почти никогда не будет использоваться 6 ГБ свопа на HDD, однако они понадобятся, если я захочу отправить компьютер в спящий режим в условиях большой загрузки оперативной памяти. (На самом деле у меня отключен zram).

На офисных ПК с 4 ГБ ОЗУ (Xubuntu 16.04, 17.10) всегда ставлю пакет zram-config. Chromium, по наблюдениям, на глаз, очень хорошо сжимается в оперативной памяти, в результате чего zram позволяет сделать работу намного более комфортной без модернизации железа.

Быстро вырубить программу, перегружающую ОЗУ. Запас ОЗУ для SSH

Бывает такое, что даже при vm.swappiness=60 какому-то черту, как правило, браузеру, требуется очень много оперативной памяти, и система подвисает.

Решается очень просто: сочетание клавиш Alt+SysRq(PrintScreen)+F заставляет oom_killer принудительно включиться и вырубить процесс, который на момент вызова занимает больше всего памяти. Строго 1 процесс на 1 вызов, и строго обязательно что-то будет убито.

Если много раз подряд нажмете, то, скорее всего, перезапустится графическая сессия. Событие убиения процесса отражается в dmesg красным цветом.

Однако эта штука, называющаяся Magic SysRq, из коробки отключена в большинстве дистрибутивов, потому что непривилегированный пользователь может убить абсолютно любой процесс. За это отчечает параметр ядра kernel.sysrq, узнать его текущее значение можно так:

sysctl kernel.sysrq.

Для работы Alt+SysRq+F нужно kernel.sysrq=1. Для этого отредатируем параметры ядра, расположенные в файлах /etc/sysctl.conf (обычно симлинк на /etc/sysctl.d/99-sysctl.conf) и /etc/sysctl.d/*.conf. Лучше всего создать отдельный файл:

sudo nano /etc/sysctl.d/99-dumalogiya.conf

В него запишем:# включить все комбинации Alt+SysRq, в т.ч. Alt+SysRq+F для принудительного вызова OOM Killer
kernel.sysrq = 1
# с 8 МБ увеличим размер памяти, который будет гарантированно не занят в системе, чтобы у нас могли работать SSH и пр.
vm.admin_reserve_kbytes = 60192
Нажмем Ctrl+O, Enter для сохранения.

В случае с браузером Chromium Alt+SysRq(PrintScreen)+F будет вырубать по одной вкладке, не закрывая сам браузер, что очень удобно.Сочетания клавиш Magic SysRq перехватываются напрямую ядром Linux, поэтому работают даже когда из-за очереди процессора подвисает X-сервер. vm.

admin_reserve_kbytes — это размер оперативной памяти в килобайтах, который будет держаться гарантированно свободным для административных нужд, например, работы SSH. По умолчанию что-то около 8 МБ. Целесообразно увеличить, число 60192 почти от балды.

Я опакетил файл /etc/sysctl.d/99-dumalogiya.

conf в deb-пакет dumalogiya-sysctl, который положил в свой репозиторий и ставлю на все компьютеры, очень удобно, можно централизованно обновлять конфиг, и не нужно настраивать вручную каждую машину. В качестве инструкции по сборке простых deb-пакетов «на коленке» рекомендую https://debian.pro/1390.

Репозиторий создал с помощью aptly, который просто создает структуру файлов и папок внутри директории веб-сервера.

Источник: https://habr.com/post/344836/

Управление памятью в Linux

Библиотека сайта rus-linux.net

Оригинал: «Linux memory management» Автор: Riccardo Capecchi Дата публикации: June 22, 2012 Перевод: Н.Ромоданов

Дата перевода: август 2012 г.

Я думаю, что обычно у каждого пользователя Linux рано или поздно возникает следующий вопрос, задаваемый при администрировании рабочей станции или сервера — «Почему в Linux используется вся моя оперативная память, хотя никакой большой работы не выполняется? «.

К нему сегодня я добавлю еще один вопрос, который, я уверен, обычен для многих системных администраторов Linux — «Почему команда free показывает память swap и почему у меня так много свободной оперативной памяти?», так что сегодняшнее мое исследование SwapCached, которое я представляю вам, может оказаться полезным, либо, по крайней мере, ознакомит, как я надеюсь, с информацией об управлении памятью в системе Linux.

Читайте также:  Установить netbeans ide самый популярный редактор кода для linux

В Linux применяется следующее основное правило: неиспользуемая страница оперативной памяти считается потерянной памятью. Оперативная память тратится не только для данных, используемых прикладными приложениями.

В ней также хранятся данные для самого ядра и, самое главное, в эту память могут отображаться данные, хранящиеся на жестком диске, что используется для супер-быстрого к ним доступа — команда top указывает об этом в столбцах «buffers/cache» («буферы / кэш»), «disk cache» («дисковый кэш)» или «cached» («кэшировано»).

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

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

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

Ниже приведены данные, выдаваемые на моем старом ноутбуке с системой Xubuntu:

xubuntu-home:~# free total used free shared buffers cached
Mem: 1506 1373 133 0 40 359
-/+ buffers/cache: 972 534
Swap: 486 24 462

В строке -/+ buffers/cache показывается, сколько памяти используется и сколько памяти свободно с точки зрения ее использования в приложениях. В этом примере приложениями уже используется 972 Мб памяти и еще 534 МБ памяти могут быть использованы.

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

Но если вы хотите получить более подробную информацию о вашей памяти, то вы должны проверить файл /proc/meminfo; в моей системе Xubuntu с ядром 3.2.0-25-generic результат будет следующим:

xubuntu-home:~# cat /proc/meminfo MemTotal: 1543148 kB
MemFree: 152928 kB
Buffers: 41776 kB
Cached: 353612 kB
SwapCached: 8880 kB
Active: 629268 kB
Inactive: 665188 kB
Active(anon): 432424 kB
Inactive(anon): 474704 kB
Active(file): 196844 kB
Inactive(file): 190484 kB
Unevictable: 160 kB
Mlocked: 160 kB
HighTotal: 662920 kB
HighFree: 20476 kB
LowTotal: 880228 kB
LowFree: 132452 kB
SwapTotal: 498684 kB
SwapFree: 470020 kB
Dirty: 44 kB
Writeback: 0 kB
AnonPages: 891472 kB
Mapped: 122284 kB
Shmem: 8060 kB
Slab: 56416 kB
SReclaimable: 44068 kB
SUnreclaim: 12348 kB
KernelStack: 3208 kB
PageTables: 10380 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1270256 kB
Committed_AS: 2903848 kB
VmallocTotal: 122880 kB
VmallocUsed: 8116 kB
VmallocChunk: 113344 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 4096 kB
DirectMap4k: 98296 kB
DirectMap4M: 811008 kB

Что означает MemTotal (Всего памяти) и MemFree (Свободная память), понятно для всех; остальные значения поясняются дальше:

Cached

Страничный кэш в системе Linux («Cached:» в meminfo) является в большинстве систем самым крупным потребителем памяти. Каждый раз, когда вы выполняете операцию чтения read () из файла, расположенного на диске, данные считываются в память и помещаются в страничный кэш.

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

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

dentry/inode caches

Каждый раз, когда вы в файловой системе выполняете операцию «ls’» (или любую другую операцию: open(), stat() и т.д.), ядру требуются данные, которые находятся на диске.

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

Таким же самым образом, как кэширование страниц в приведенных выше примерах, ядро может после того, как будет завершена команда «ls», стереть эти структуры. Тем не менее, делается такое же предположение, как и раньше: если вы однажды считали эти данные, вы обязательно прочитаете их еще раз.

Ядро хранит эту информацию в нескольких местах «кэша», которые называются кэш памятью dentry и inode. Кэш память dentries являются общей для всех файловых систем, но каждая файловая система имеет свой собственный кэш inodes.

Эта оперативная память является в meminfo составной частью «Slab:»

Вы можете просмотреть различную кэш память и узнать ее размеры с помощью следующей команды:

head -2 /proc/slabinfo; cat /proc/slabinfo | egrep dentry|inode

Buffer Cache

Кэш буфера («Buffers:» в meminfo) является близким родственником кэш памяти dentry/inode. Данные dentries и inodes, размещаемые в памяти, представляют собой описание структур на диске, но располагаются они по-разному.

Это, возможно, связано с тем, что у нас в копии, расположенной в памяти, используется такая структура, как указатель, но на диске ее нет.

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

Отображение памяти в команде top: VIRT, RES и SHR

Если вы запускаете команду top, то три строки будут описывать к использованию памяти. Вы должны понимать их значение с тем, чтобы понять, сколько памяти требуется вашему серверу.

VIRT является сокращением от virtual size of a process (виртуальный размер процесса) и представляет собой общий объем используемой памяти: памяти, отображаемой самой в себя (например, памяти видеокарты для сервера X), файлов на диске, которые отображаются в память (особенно это касается разделяемых библиотек) и памяти, разделяемой совместно с другими процессами. Значение VIRT указывает, сколько памяти в настоящий момент доступно программе.

RES является сокращением от resident size (размер резидентной части) и является точным указателем того, сколько в действительности потребляется процессом реальной физической памяти. (Что также соответствует значению, находящемуся непосредственно в колонке %MEM). Это значение практически всегда меньше, чем размер VIRT, т.к. большинство программ зависит от библиотеки C.

SHR показывает, какая величина от значения VIRT является в действительности разделяемой (по памяти или за счет использования библиотек). В случае библиотек, это не обязательно означает, что вся библиотека находится в резидентной памяти.

Например, если программа использует только несколько функций библиотеки, то при отображении в память будет использована вся библиотека, что будет учтено в значениях VIRT и SHR, но, на самом деле, будет загружена часть библиотеки, содержащая используемые функции, и это будет учтено в значении RES.

Подкачка памяти — swap

Теперь мы видим некоторую информацию о нашей оперативной памяти, но что происходит, когда больше нет свободной оперативной памяти? Если у меня нет свободной памяти, а мне нужна память для страничного кэширования, кэширования inode или кэширования dentry, то где я ее могу получить?

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

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

Это обусловлено тем, что нашему ядру требуется своего рода «рабочее пространство» для выполнения своих действий, и поэтому, если размер свободной оперативной памяти становится равным нулю, ядро ничего больше сделать не сможет.

На основании общего объема оперативной памяти и соотношения ее различных типов (память high/low), ядро эвристически определяет то количество памяти в качестве рабочего пространства, при котором оно чувствует себя комфортно. Когда эта величина достигается, ядро начинает возвращать память для других различных задач, описанных выше. Ядро может вернуть себе память из любой из этих задач.

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

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

В ходе этого процесса оно получает данные пользовательских приложений и записывает их в специальное место (или места) на диске.

Обратите внимание, что это происходит не только тогда, когда оперативная память близка к заполнению, ядро может принять решение перенести в память swap также данные, находящиеся в оперативной памяти, если они некоторое время не использовались (смотрите раздел «Подкачка памяти»).

По этой причине, даже система с огромным количеством оперативной памяти (даже если ее правильно настроить) может использовать память подкачки swap. Есть много страниц памяти, в которых находятся данные пользовательских приложений, но эти страницы используются редко. Все это является причиной, чтобы перенести их в раздел swap и использовать оперативную память для других целей.

Вы можете с помощью команды free проверить, используется ли память swap; для примера, который я уже использовал выше, в последней строке выдаваемых данных показывается информация о размере памяти swap:

xubuntu-home:~# free total used free shared buffers cached
Mem: 1506 1373 133 0 40 359
-/+ buffers/cache: 972 534
Swap: 486 24 462

Мы видим, что на этом компьютере уже используется 24 мегабайта памяти swap и для использования доступно еще 462 Мб.

Таким образом, сам факт использования памяти swap не является доказательством того, что в системе при ее текущей рабочей нагрузке слишком мало оперативной памяти.

Лучший способ это определить с помощью команды vmstat — если вы увидите, что много страниц памяти swap перемещаются на диск и обратно, то это означает, что память swap используется активно, что система «пробуксовывает» или что ей нужна новая оперативная память поскольку это ускорит подкачку данных приложений.

На моем ноутбуке Gentoo, когда он простаивает, это выглядит следующим образом:

~ # vmstat 5 5
procs ————memory———- —swap— ——io—- -system— —-cpu—- r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 0 2802448 25856 731076 0 0 99 14 365 478 7 3 88 3 0 0 0 2820556 25868 713388 0 0 0 9 675 906 2 2 96 0 0 0 0 2820736 25868 713388 0 0 0 0 675 925 3 1 96 0 2 0 0 2820388 25868 713548 0 0 0 2 671 901 3 1 96 0 0 0 0 2820668 25868 713320 0 0 0 0 681 920 2 1 96 0

Обратите внимание на то, что в выходных данных команды free у вас есть только 2 значения, относящихся к памяти swap: free (свободная память) и used (используемая память), но для памяти подкачки swap также есть еще одно важное значение: Swap cache (показатель кэширования памяти подкачки).

Кэширование памяти swap (Swap Cach)

Кеширование памяти swap по сути очень похоже на страничное кеширование. Страница данных пользовательского приложения, записываемая на диск, очень похожа на страницу данных файла, находящуюся на диске. Каждый раз, когда страница считывается из файла подкачки («si» в vmstat), она помещается в кэш подкачки.

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

Это избавит нас от затрат на переписывание страницы на диск.

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

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

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

Поэтому, чтобы узнать, что память swap действительно используется, мы должны из значения SwapUsed вычесть значение SwapCached, вы можете найти эту информацию в /proc/meminfo.

Подкачка памяти

Когда приложению нужна память, а вся оперативная память полностью занята, то в распоряжении ядра есть два способа освободить память: оно может либо уменьшить размер дискового кэша в оперативной памяти, убирая устаревшие данные, либо оно может сбросить на диск в swap раздел несколько достаточно редко используемых порций (страниц) программы. Трудно предсказать, какой из способов будет более эффективным. Ядро, исходя из недавней истории действий в системе, делает попытку приблизительно отгадать на данный момент эффективность каждого из этих двух методов.

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

Подкачке памяти назначается значение от 0 до 100, которое изменяет баланс между подкачкой памяти приложений и освобождением кэш памяти.

При значении 100 ядро всегда предпочтет найти неактивные страницы и сбросить их на диск в раздел swap; в других случаях этот сброс будет осуществляться в зависимости от того, сколько памяти занимает приложение и насколько трудно выпонять кэширование при поиске и удалении неактивных элементов.

По умолчанию для этого устанавливается значение 60. Значение 0 дает нечто близкое к старому поведению, когда приложения, которым нужна память, заставляли немного уменьшить размер кэша оперативной памяти. Для ноутбуков, для которых предпочтительно иметь диски с меньшей скоростью вращения, рекомендуется использовать значение 20 или меньше.

Заключение

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

Если вам понравилась статья, поделитесь ею с друзьями:

Источник: http://rus-linux.net/MyLDP/sys-conf/memory.html

Ссылка на основную публикацию