Страница 1 из 1
7.1: async and gjournal
Добавлено: 2008-12-29 17:24:46
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)
Мне последний резльтат больше всего нравится!
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 17:48:45
Fastman
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)
Мне последний резльтат больше всего нравится!
Во первых. Ты тестишь на линейный поток. Поэтому данные цифры - сферический конь в вакууме.
IMAP и почтовые ящики дадут другой тип нагрузки, и все будет упираться не в линейное чтение/запись
а в количестве IO операций, т.к файлов будет много и они мелкие.
Поэтому гораздо важнее не скорость а надежность и количество IO операций, что зависит от мощи контроллера
диска.
Поэтому рекомендуется при большем количестве ящиков и хорошей почтовой нагрузке ставить нормальный контроллер
и ваять RAID.
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 17:52:09
Laa
Ну про RAID понятно.
По тому что есть что можно добавить или дополнить!?
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 18:02:03
Fastman
Laa писал(а):Ну про RAID понятно.
По тому что есть что можно добавить или дополнить!?
Ничего и вообще async не очень хорошо будет влиять на надежность
Оно же по сути дела включает кэширование при записи, что не есть гуд...
То есть фишка в чем.. что система еще не поместив реально данные на диск а только в кэш -
скажет се окей пишем дальше и только потом асинхронно запишет данные.
Поэтому при пропадании электроэнергии в этот момент никто не гарантирует целостность данных.
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 18:06:11
Laa
Как это никто?!
gjournal не гарантирует?
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 18:14:55
Fastman
Laa писал(а):Как это никто?!
gjournal не гарантирует?
Интересно..а как журналирование может гарантировать отсутствие сбоя при выключении питания ?
Журналирование - ведение лога изменений файловой системы.
Наличие журнала повышает вероятность сохранения целостности файловой системы хранятся записи фактических изменений
И эти записи хранятся до тех пор, пока они не будут целиком и безопасно применены.
Как известно - вероятность сохранности увеличивается - но ни в коем случае не гарантируется.
И если во время сбоя по питаю данные не были сохранены на веник и журнал не записал ничего - то и восстановить тоже ничего нельзя
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 18:28:59
Laa
OK.
Поставлю вопрос по-другому.
Есть freebsd 7.1, диск на 300 Gb.
Как оптимальней в этом окружении настроить почту imap/exim/mysql.
Критерии: скорость, надежность и перспективность (чтобы несколько лет не морочить голову).
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 18:56:56
Fastman
Laa писал(а):OK.
Поставлю вопрос по-другому.
Есть freebsd 7.1, диск на 300 Gb.
Как оптимальней в этом окружении настроить почту imap/exim/mysql.
Критерии: скорость, надежность и перспективность (чтобы несколько лет не морочить голову).
сколько юзеров ? какая нагрузка ? Обьем хранения ? Прирост почты в месяц ?
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 19:10:12
Laa
Ящиков под 1000. Пока. Возможен рост. Прямо доменами.
Сейчас под 50гб почты на существующих ящиках.
Прирост стабильный.
Re: 7.1: async and gjournal
Добавлено: 2008-12-29 19:27:21
Fastman
Laa писал(а):Ящиков под 1000. Пока. Возможен рост. Прямо доменами.
Сейчас под 50гб почты на существующих ящиках.
Прирост стабильный.
Тогда прийдется апгрейдить дисковую систему.
В простейшем случае 2 веника в зеркало только под почту. И желательно веники 750Gb.
Иначе с вашей 300-кой вы через полгода все упрется в нехватку места.
Работать с матюками будет и тормозно.
В идеальном варианте - RAID 10 из 4/6-х веников. Плюс бэкап.
Я не говорю что на этом одном венике работать не будет.. Будет обязательно.
Но надежность решения - просто ниже плинтуса будет.
Решите просто что терпит..надежность или финансы.
Добавлю еще.. при 1000 пользователей про SATA веники можно забыть как про страшный сон...
Это реальность
))
Re: 7.1: async and gjournal
Добавлено: 2008-12-30 15:35:00
iZEN
Laa писал(а):Ну про RAID понятно.
По тому что есть что можно добавить или дополнить!?
Ещё можно включить noatime.
Re: 7.1: async and gjournal
Добавлено: 2008-12-30 15:46:40
Laa
А как noatime может влиять на работу почтовых ящиков IMAP?
Re: 7.1: async and gjournal
Добавлено: 2008-12-30 16:02:36
iZEN
Laa писал(а):А как noatime может влиять на работу почтовых ящиков IMAP?
/etc/fstab:
Код: Выделить всё
...
/dev/ad4s1e.journal /var ufs rw,async,noatime 2 2
...
Не будет обновляться время последнего доступа к файлам и каталогам на журналируемом разделе.
Re: 7.1: async and gjournal
Добавлено: 2008-12-30 16:32:20
Laa
Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить
Я хочу понять как оно будет влиять на IMAP.
Re: 7.1: async and gjournal
Добавлено: 2008-12-30 17:42:30
Fastman
Laa писал(а):Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить
Я хочу понять как оно будет влиять на IMAP.
Работа с IMAP - работа с большим количеством мелких файлов(писма в мэйлдире юзверей)
В обычном режиме при доступе к файлам обновляется время доступа - это требует времени.
При отключении - доступ к файлам ускоряется.
Но вас на 1000 юзероф это не спасет
Re: 7.1: async and gjournal
Добавлено: 2008-12-31 8:54:44
Laa
А IMAP-сервер (dovecot) не использует информацию о доступе к файлам? Ту которую попоротит noatime?
Re: 7.1: async and gjournal
Добавлено: 2008-12-31 10:21:29
fxp
нет не использует.
Re: 7.1: async and gjournal
Добавлено: 2008-12-31 16:22:46
iZEN
Laa писал(а):Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить
Я хочу понять как оно будет влиять на IMAP.
IMAP — это протокол с установлением соединения на просмотр и чтение каждого письма. Ведь так? Значит нужно ещё оптимизировать систему по количеству одновременных сетевых соединений. Может оказаться так, что затык будет не на дисковых хранилищах, а в сетевой подсистеме.
Re: 7.1: async and gjournal
Добавлено: 2008-12-31 17:50:01
Fastman
iZEN писал(а):Laa писал(а):Да я прекрасно понимаю действие noatime, прекрасно понимаю как его включить, даже знаю что можно еще кое-что включить
Я хочу понять как оно будет влиять на IMAP.
IMAP — это протокол с установлением соединения на просмотр и чтение каждого письма. Ведь так? Значит нужно ещё оптимизировать систему по количеству одновременных сетевых соединений. Может оказаться так, что затык будет не на дисковых хранилищах, а в сетевой подсистеме.
Сеть это понятно... Количество одновременно открытых файловых дескрипторов... пропускная способность итд.
Но в конце концов ширины даже 100 мегабитки хватит для нормальной работы в общем то.
В принципе я думаю автору топика просто стоит попробовать
И поглядеть на очередь доступа к диску при соединении 25% от всех его юзеров