Анаконда, своп и производительность

>А ведь всегда считалось, что расположение Swap первым на жестком диске повышает производительность системы,

это если у тебя 16 мегабайт памяти, а если 4 гигабайта и ты яву не используешь, то не важно

а если вручную разметить, например fdisk'ом?

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

Друзья, я прекрасно понимаю ваши советы разбить fdisk'ом (так и делаю, кстати), накинуть память (само собой), но в данном случае мня интересует только два вопроса: 1) правильно ли поступает своенравная Анаконда или это ее баг? 2) каков прирост производительности системы при расположение свопа первым? В предположении, что иногда происходит к нему обращение.

1) хз
2) хз, но он должен быть, чисто теоретически.

Я же не ставил такой вопрос "должен он быть или нет". Вопросы были совсем другие - см. 1) и 2). Кроме "хз", более информативный ответ будет?

мне что, и погуглить за тебя чтоли?

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

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

Конечно, принципиально. Если баг - значит, надо точно также начхать на анакондовскую разбивку и делать вручную так, как считаем нужным.

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

да, и кстати, не забываем также о том, что порядок следования цилиндров/секторов, показываемый parted'ом, fdisk'ом и прочими, не всегда имеет прямое отношение к действительности...

С другой стороны - а если Анаконда права? И мы в этом вопросе чего-то до конца не знаем?

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

Не то разобьешь его не так, запустишь его лет эдак на 5 без остановки, а потом всплывут "вновь открывшиеся обстоятельства", из которых стало ясно, что разбил диск неправильно. И потом придется каждый день вспоминать "А ведь можно было бы, если хорошо подумать, сделать лучше!" и рвать волоса на лысине :)

PS: я бы на вашем месте поместил своп вторым или третьим разделом и не заморачивался бы особо по этому поводу. я не думаю что сейчас реально выжать даже 1-2 процента увеличения производительности системы в зависимости от местоположения свопа.

> не всегда имеет прямое отношение к действительности...

Ну да, ну да, и каков же вывод? :)

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

> я не думаю что сейчас реально выжать даже 1-2 процента увеличения производительности системы в зависимости от местоположения свопа.

Эти рассуждения подкреплены чем-то фактическим или так просто?

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

> кстати, как вариант "чтобы не думалось" - сделать своп на отдельном винте. вот тогда уж точно побыстрее будет. Как вариант - да, и это не новость, но это опять-таки, это не тот случай, который прошу обсуждать в данном топике. Речь идет сугубо о оптимальной разбивке одного диска.

> Эти рассуждения подкреплены чем-то фактическим или так просто?

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

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

повышенного износа механики явно не будет ни при каком раскладе. срок службы механики (если она сразу не полетит конечно, что может говорить лишь только о качестве железа) для современных винчестеров превышает срок возможного износа покрытия блинов.
кстати, следует заметить, что для сервера своп - это уже эдакий "последний рубеж". не должно быть таких ситауций когда система "застревает" в свопе. скидывать туда малоиспользуемые данные, или просто резервировать там место, на всякий случай - это да, допускается (и в этом случае скорость работы свопа опять же не принципиальна).
но "работать из свопа" система не должна. поэтому все-таки нужно больше беспокоиться о наличии достаточного количества оперативной памяти.
если есть хотя бы только сомнения что на одном сервере будет даже возможность того что система застрянет в свопе, лучше подумать о возможности организации load balancing кластера либо разноса сервисов на разные сервера.
JFYI.

Кластеры пока не грозят из-за финансовых соображений :) А вот своп выручал не раз, даже при избытке оперативной памяти. Бывает, что месяцами к нему практически нет обращений. Но потом ни с того не с сего (ДДоС, жуткое нашествие ботов и т.п.) оперативка переполняется, и начинает трещать своп. Трещит он долго, пока внешняя ситуация не рассосется. И если свопа выделено мало, тогда опс! - сервер не выходит из коллапса :(

ну такие ситуации же не каждый день бывают чтобы из-за этого так беспокоиться. выделить 15-20 гигов под своп в любом месте диска и забыть.
btw, ддос и нашествия ботов лучше пресекать заранее а не ждать пока оно достигнет своей цели :)

Пожалуй, что так. Спасибо.