7.1: async and gjournal

[Laa]

Hi! С наступающим НГ всех! Стабильности, здоровья и мира!!!

Поставил 7.1-PRERELEASE, включил журналирование на всех разделах.
Диск ad0: 305244MB <WDC WD3201ABYS-01B9A0 13.01C02> at ata0-master SATA150

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

Вот какие мои результаты (dd 100m из /dev/zero в файл и из файла в /dev/null):

без async:
read : 181640484 bytes/sec
write: 25889991 bytes/sec

с async:
read : 180109552 bytes/sec
write: 32090450 bytes/sec

Видно, что скорость записи с async стала выше. Скорость чтения меня устраивает и так.
Вопрос -- как еще можно увеличить скорость записи на этот раздел?
Раздел планируется использовать для почтовых ящиков IMAP.

Пока писал попробовал с noexec, быстрее значительно не стало.
Но пока несколько тестов делал получил результаты такие 26429143 bytes/sec, 17748899 bytes/sec, 56330203 bytes/sec)
Мне последний резльтат больше всего нравится!

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Fastman]

Hi! С наступающим НГ всех! Стабильности, здоровья и мира!!!

Поставил 7.1-PRERELEASE, включил журналирование на всех разделах.
Диск ad0: 305244MB <WDC WD3201ABYS-01B9A0 13.01C02> at ata0-master SATA150

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

Вот какие мои результаты (dd 100m из /dev/zero в файл и из файла в /dev/null):

без async:
read : 181640484 bytes/sec
write: 25889991 bytes/sec

с async:
read : 180109552 bytes/sec
write: 32090450 bytes/sec

Видно, что скорость записи с async стала выше. Скорость чтения меня устраивает и так.
Вопрос -- как еще можно увеличить скорость записи на этот раздел?
Раздел планируется использовать для почтовых ящиков IMAP.

Пока писал попробовал с noexec, быстрее значительно не стало.
Но пока несколько тестов делал получил результаты такие 26429143 bytes/sec, 17748899 bytes/sec, 56330203 bytes/sec)
Мне последний резльтат больше всего нравится!

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

[Laa]

Ну про RAID понятно.

По тому что есть что можно добавить или дополнить!?

[Fastman]

Ну про RAID понятно.

По тому что есть что можно добавить или дополнить!?

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

[Laa]

Как это никто?!
gjournal не гарантирует?

[Fastman]

Как это никто?!
gjournal не гарантирует?

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

[Laa]

OK.

Поставлю вопрос по-другому.
Есть freebsd 7.1, диск на 300 Gb.
Как оптимальней в этом окружении настроить почту imap/exim/mysql.
Критерии: скорость, надежность и перспективность (чтобы несколько лет не морочить голову).

[Fastman]

OK.

Поставлю вопрос по-другому.
Есть freebsd 7.1, диск на 300 Gb.
Как оптимальней в этом окружении настроить почту imap/exim/mysql.
Критерии: скорость, надежность и перспективность (чтобы несколько лет не морочить голову).

сколько юзеров ? какая нагрузка ? Обьем хранения ? Прирост почты в месяц ?

[Laa]

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

[Fastman]

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

Тогда прийдется апгрейдить дисковую систему.
В простейшем случае 2 веника в зеркало только под почту. И желательно веники 750Gb.
Иначе с вашей 300-кой вы через полгода все упрется в нехватку места.
Работать с матюками будет и тормозно.

В идеальном варианте - RAID 10 из 4/6-х веников. Плюс бэкап.
Я не говорю что на этом одном венике работать не будет.. Будет обязательно.
Но надежность решения - просто ниже плинтуса будет.
Решите просто что терпит..надежность или финансы.

Добавлю еще.. при 1000 пользователей про SATA веники можно забыть как про страшный сон...
Это реальность ))

[iZEN]

Ну про RAID понятно.

По тому что есть что можно добавить или дополнить!?

Ещё можно включить noatime.

[Laa]

А как noatime может влиять на работу почтовых ящиков IMAP?

[iZEN]

А как noatime может влиять на работу почтовых ящиков IMAP?

/etc/fstab:

Код: Выделить всё

...
/dev/ad4s1e.journal	/var		ufs	rw,async,noatime		2	2
...

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

[Laa]

Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить

Я хочу понять как оно будет влиять на IMAP.

[Fastman]

Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить

Я хочу понять как оно будет влиять на IMAP.

Работа с IMAP - работа с большим количеством мелких файлов(писма в мэйлдире юзверей)
В обычном режиме при доступе к файлам обновляется время доступа - это требует времени.
При отключении - доступ к файлам ускоряется.
Но вас на 1000 юзероф это не спасет

[Laa]

А IMAP-сервер (dovecot) не использует информацию о доступе к файлам? Ту которую попоротит noatime?

[fxp]

нет не использует.

[iZEN]

Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить

Я хочу понять как оно будет влиять на IMAP.

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

[Fastman]

Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить

Я хочу понять как оно будет влиять на IMAP.

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

Сеть это понятно... Количество одновременно открытых файловых дескрипторов... пропускная способность итд.
Но в конце концов ширины даже 100 мегабитки хватит для нормальной работы в общем то.

В принципе я думаю автору топика просто стоит попробовать И поглядеть на очередь доступа к диску при соединении 25% от всех его юзеров