Автор статьи "Linux: Using Multiple Swap Partitions In 2.4 (http://kerneltrap.org/node/5247)" утверждает, что разбив один 512 Мб раздел подкачки на 4 swap раздела по 128 Мб, производительность при своппинге увеличилась почти в два раза.URL: http://kerneltrap.org/node/5247
Новость: http://www.opennet.me/opennews/art.shtml?num=5614
А если создать виртуальный диск в ОЗУ и разместить эти файлы подкачки там, то вообще все будет летать аки Феррари.По теме: Козе понятно, что если разместить файлы на разных дисках, то производительность увеличивается. Только радости от этого мало. Если вы имеете интенсивный своп, то система долго не проживет. Факт!
если бы вы прочитали статью перед тем как высказывать своё мнение, то заметили бы, что все свап-раздулы находятся на одном HDD hda
А вот это как раз и н глупо. Это только увеличваеи время поиска нужного файла...
А на разных дисках сокращает...
о свапе в рамдиске:
производительность системы действительно будет выше чем если этот самый свап выключить, чем это обьясняется незнаю, но был проведён данный опыт и результаты проверены несколько раз на разных машинах .
Вы действительно не знаете или прикалываетесь?
Там уже обсуждают как использовать память на видео и аудиокартах для подкачки. Еще бы: поставить на сервер Радеон с 512 мегабайт и вперед. А еще лучше три Радеона и застрипить...
Память стоит копейки. Может добавить и не париться?
Если сервер свопит - это уже не сервер.
Статью не читал, но такой вопрос возник:
Как часто бывает, чтобы своп был забит больше чем на 10 мегабайт, считая что имеем хотя бы 256 оперативы(уже редко встретишь < 256)? Про десктопы ваще молчу, он там вообще не нужен.
У меня на desktop'е 88 дней uptime и в свопе 400Мб при 512Мб оперативки. Все летает, т.к. в своп выгружены страничы процессов коротые редко исмпользуются.
Чушь галимая.
Почитай ка http://www.itworld.com/ad_refresh_336x280.htm?id=aci
Вырезка
....
Swap performance only makes a difference when you are short of RAM.
....
все зависит от реализации vm в ОС. в линуксе при отключении свопа на ядре 2.4, я никаких косяков не заметил(рам=512). в винде2000 же при этом же объеме рам с отлюченным свопом многие проги начинали конкретно глючить. как в других ОС - не знаю.
Ну какой мне интерес тут лапшу развешивать, или мы не об одном и том же:
[nick@nick nick]$ uptime
00:00:27 up 90 days, 10:42, 2 users, load average: 1.28, 0.90, 0.79
[nick@nick nick]$ uname -a
Linux nick 2.6.11 #1 Fri Mar 4 18:52:06 MSK 2005 i686 i686 i386 GNU/Linux
[nick@nick nick]$ free
total used free shared buffers cached
Mem: 508828 502808 6020 0 72836 238076
-/+ buffers/cache: 191896 316932
Swap: 987988 296264 691724Swap за выходные подхудел ;-)
Type Percent Capacity Free Used Size
Physical Memory 17% 3.20 GB 683.76 MB 3.87 GB
Disk Swap 0% 5.00 GB 0.00 KB 5.00 GB
У меня на рабочем десктопе 1G RAM + 2G swap -- случается, нехватает.
Приходится временно dd of=big.file -- делать swap в файле
Объясните пожалуйста какой смысл делать фаил подкачки в RAM если обрашение к этому фаилу происходит при нехватке оперативной памяти?
Может в целях отладки ядра?
Может не давать ядру много кешировать (хотя это можно через опции настроить)?
Может в системах с виртуальными серверами (аля FreeBSD jail или virtual chroot) такое полезно.
В любом случае должны быть веские причины.Вот например /tmp в RAMFS разместить смысл есть.
кеш винта работает быстрее.
>Объясните пожалуйста какой смысл делать фаил подкачки в RAM если >обрашение к этому фаилу происходит при нехватке оперативной памяти?Такая схема используется в встраиваемых системах ,где ось инсталлируется на флэш-диски.
>Объясните пожалуйста какой смысл делать фаил подкачки в RAM если
>обрашение к этому фаилу происходит при нехватке оперативной памяти?Не совсем верно понимаешь. Система не обращается к свопу при нехватке оперативной памяти - в том смысле, что она не трактует своп как добавок к оперативке. Система *вытесняет* в своп страницы, которые редко используются. Типа, у тебя болтается в памяти процесс, используемый раз в сутки, зачем его держать в оперативке? Пусть перелезает в своп, а оперативку отдадим кому-нибудь более полезному.
Если оперативки мало, то конечно, вытесняться будут и страницы, обращение к которым происходит не слишком редко; результат - ухудшение производительности.
А в общем, это кажется у Немет достаточно подробно расписано.
Если своп в RAM предназначен для вытеснения малоиспользуемых страниц, то почему бы просто не выключить своп?
По вашему получается, что если на машине с, к примеру, 1 ГБ ОЗУ и 2 ГБ свопа загрузить прикладуху размером, к примеру же, 512 МБ, и никак эту самую прикладуху не трогать, то через некоторое время она вся окажется в свопе?
>По вашему получается, что если на машине с, к примеру, 1 ГБ
>ОЗУ и 2 ГБ свопа загрузить прикладуху размером, к примеру же,
>512 МБ, и никак эту самую прикладуху не трогать, то через
>некоторое время она вся окажется в свопе?зы. Не трогать не только эту прикладуху, но и всю машину. Вообще ничего на этой машине не делать.
Там все немного сложнее. Так вопрос ставить некорректно.
Любая аппликация линкуется с кучей библиотек, то-есть уже нельзя сказать, что "вся". Зависит от реализации, кроме того. Много от чего зависит.
Но в первом приближении можно сказать, что да. Вся, или ее часть.
> Типа, у тебя болтается в памяти процесс, используемый раз в сутки, зачем его держать в оперативке?
Ну это еще от реализации зависит
Кто-нибудь может нормально объяснить за счет чего 4 раздела свапа по 128 мег работаю быстрее чем один 512 Мег?
да статейка про разглагольствв..ни методологии ни показателей производительности ни чего....:-)) тока какие-то скрины, где какой своп находится..
1. Имеем 4 раздела свапа по 128 мег на одном диске.
По-фантазируем...Система выгрузила 8 файлов в свап разделы. Предположим, что каждый свап получил по 2 файла...
Сколько времени потребуется системе, чтобы прочитать эти файлы?|-A-B-|-C-D-|-E-F-|-K-L-| /dev/hda
|----- 8 миллисекунд ---|
... чтобы прочитать эти файлы считывающее устройство должно сделать 8 движений по диску. ( примем что на поиск и прочтение уходит 1 миллисекунда ). Вобщем - 8 миллисекунд.2. Имеем 4 раздела свапа по 128 мег на разных дисках.
|-A-B-| /dev/hda
|-C-D-| /dev/hdb
|-E-F-| /dev/hdc
|-K-L-| /dev/hdd|-2мs-|
... чтобы прочитать эти файлы 4 считывающих устройств одновременно начинают поиск и каждое сделает только 2 движения по диску. Вобщем - 2 миллисекунды
А от размеров свапа скорость чтения независит..
Со свапами по 128 мег на разных разделах итак понятно. Насколько я понял при прочтении статьи, дело именно в приросте производительности свапа при размешении 4-х разделов 128Мег на одном физическом устройстве
что подтверждает цитата:
"...And you will then modify it and add entries so it reads, for example:/dev/hda6 swap swap sw, pri=8 0 0
/dev/hda7 swap swap sw, pri=8 0 0
/dev/hda8 swap swap sw, pri=8 0 0
/dev/hda9 swap swap sw, pri=8 0 0
Then, after saving this file, you can reboot and see if everything..."
Остается непонятна причина прироста при таком размещении файлов подкачки
>Система выгрузила 8 файлов в свап разделы. Предположим, что каждый свап получил
>по 2 файла...какие файлы? в своп падают не файлы а _страницы_
>Остается непонятна причина прироста при таком размещении файлов подкачки... меня терзают смутные сомнения в отношении компетентности автора этой статьи...
... стоит ли доверять этой информации...
Я тут чего подумал, а ведь это же офигенная идея, свопить в память видеокарты. SLI режим теоретически должен вдвойне поднять производительность системы! Чем не тема для "очередной" статьи?
>Я тут чего подумал, а ведь это же офигенная идея, свопить в
>память видеокарты. SLI режим теоретически должен вдвойне поднять производительность системы! Чем
>не тема для "очередной" статьи?
Эдак ты подложишь себе офигенную такую свинью, норма ошибок допускаемых видеопаматью на порядки выше обычной ОЗУ (а в серверах еще и ЕСС). Ибо видеопамять изрядно разогнана, тк надо быстро вывести на экран, а один битый пиксел на сотню правильных глаз не замечает, а теперь как поведет себя сервер, когда каждая сотая страничка будет битая... к бабке-гадалке пойдем?
Во-Во
И я о том же...
похоже на бред
Всё зависит от нескольких параметров:
1. а работал ли свап? в свап прилога вываливается по умолчанию в линухе через задаваемый тайм-аут или в случае если нет больше места в оперативке.
2. место расположения свапа - чем ближе к краю диска, тем чтение/запись происходит быстрее - не в разы, конечно, но есть такой эффект
Т.е. в автор мог получить ускорение от разбивки, но это не значит что это будет иметь место всегда на всех приложениях. Кроме того, такой свап - 512 Мб в общем-то и не нужен, за глаза хватит 128Мб.Тут звучала мысль о свапе в опреативку... Честное слово, не понимаю, зачем это нужно.. если хотите чтобы прилога торчала в памяти, соберите ядро с большим таймаутом выгрузки в свап и наслаждайтесь..
По-моему нужную страницу легче искать в том своп разделе где она находится. Отсюда и прирост в скорости. Другое дело каков закон роста скорости от количества и объема своп разделов? Да и чем это проверить?