Почему Подкачка используется, когда много свободной памяти оставляют?
Посмотрите на другие сценарии в /etc/init.d и необходимо видеть блок комментария заголовка LSB, который выглядит подобным этому примеру от fetchmail:
### BEGIN INIT INFO
# Provides: fetchmail
# Required-Start: $network $local_fs $remote_fs
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 1
# Short-Description: init-Script for system wide fetchmail daemon
### END INIT INFO
Этот тип блока требуется.
От man update-rc.d:
обновление-rc.d имеет два режима работы для установки сценариев в последовательность начальной загрузки. Режим прежней версии, где параметры командной строки используются для решения последовательности и runlevel конфигурации и режима по умолчанию, где зависимость и runlevel информация в init.d сценарии заголовок комментария LSB используется вместо этого. Такой заголовок требуется, чтобы присутствовать в init.d сценариях. Посмотрите insserv (8) страница руководства для получения дополнительной информации о формате заголовка LSB.
This is perfectly normal.
At system startup, a number of services start. These services initialize themselves, read in configuration files, create data structures and so on. They use some memory. Many of these services will never run again for the entire time the system is up because you're not using them. Some of them may run in hours, days, or weeks. Yet all this data is in physical memory.
Of course, the system can't throw this data away. It can't prove that it will literally never be accessed. One of those services, for example, might be the one that provides you remote access to the box. You may not have used it in a week, but if you do use it, it had better work.
But the system knows that it might like to use that physical memory for things like a disk cache or in other ways that will improve performance. So it does opportunistic swapping. When it has nothing better to do, it writes data that hasn't been used in a very long time to disk, using swap space. However, it still keeps the pages in physical memory. So they can still be accessed without having to swap them in.
Now, if the system later needs that physical memory for something else, it can simply throw those pages away because it has already written them to swap. This gives the system the best of both worlds. The data is still kept in memory, so it can be accessed without having to read it from disk. But if the system needs that memory for another purpose, it won't have to write it out first. Big win all around.
This can happen if at some time in the past you needed more memory than you have physical RAM in the machine. At that time some data will have been written to the swap space.
When later memory gets freed, data from swap is not automatically read back into RAM: this only happens when the data in swap is actually needed by some process. This is perfectly normal.
As for your mysql process: this all depends on the type of queries you run. In theory 2 very complex queries could probably suffice to get such a load, regardless of your number of users. You could enable the slow query log to gain more insight into which queries are load-intensive.
Плохо! На самом деле проблема заключалась в настройке Jboss. По умолчанию Jboss не запускается в широковещательном режиме.
Jboss 7 поставляется с установочным файлом standalone.xml с тегом , по умолчанию для него установлено значение 127.0 .0.1. Мне нужно было изменить его на
. Для получения подробной информации
--- 256857- Вы также можете изменить это поведение с помощью Что касается MySQL , выполняли ли вы хотя бы тест базовой конфигурации с помощью сценария tuning-primer.sh ? sysctl -w vm.swappiness = 10 , что значительно сократит использование свопа до тех пор, пока оно действительно не понадобится.
Вероятно, как объяснил Дэвид, это нормальное поведение ядра Linux, но это также может быть возникновением проблемы MySQL «безумие подкачки» . В вашем случае (8 ЦП, всего 16 ГБ ОЗУ, используется 5 ГБ) для этого ваш компьютер должен быть системой NUMA с 4 узлами (сокетами) и 4 ГБ ОЗУ на узел и пулом буферов MySQL InnoDB из 4 GB.
Вкратце (вы должны прочитать ссылку выше для получения полной информации), вот что происходит:
- Когда ваша система запускается, процессы распределяются по всем узлам NUMA, используя часть их памяти.
- Когда MySQL запускается, он выделяет 4 ГБ для буферного пула InnoDB, заполняя ОЗУ узла NUMA и используя некоторую ОЗУ на других узлах.
- Затем ядро Linux, которое не может перемещать выделенную ОЗУ с одного узла NUMA на другой,