Регистрация...

Eserv Forum / E4 / Mail / Хелп! Ошибка при инсталяции Eserv 4.26

wikipost // (v1)
Продукты и услуги Скачать Документация Купить Поддержка Форумы Партнёрам Статьи О компании
Ставлю на "чистый" комп скачанный сегодня Eserv 4.26...
Инсталятор долго и упорно чего-то делает и потос в левои нижнем углу выдает сообщение красным цветом: Ошибка: Unknow.
См. в лог инсталяции, последняя запись: про SMTP HeloBlackList.txt заканчивающаяся двуми "-1" и "Завершаюсь...
BYE!
Deleting temporary files... 1 1 1 1 1
EXCEPTION! CODE:C0000005 ADDRESS:60915C36 WORD:0 0 0 0 0 0 0 " . И попутно: - А чего он, конвертаров, такой тормозной? На CoreDuo E6600 (up to 3,8Ghz) лопатит часами!
 
Комментарии к этой версии (02.12.2010 12:28) [~di_line] 39c1c613
АвторДатаТекстtags
ac02.12.2010 13:08
На какой странице мастера установки он долго что-то делает?

di_line пишет: А чего он, конвертаров, такой тормозной?

Так "чистый комп" или все же нет? Вы импортируете конфиг E2 или E3, и в этот момент происходит сбой?

E4-setup.log пришлите, пожалуйста, на support@eserv.ru.
wikipost
di_line02.12.2010 13:41
Комп чисты. Так как сегодня ночью накрылись диски на почтовике.
Планировал у НГ обновить железо и сам Eserv, вот и пригодилось.
Подняли на новом железе, ну а резервных копий — как всегда, не найти. Лицензия куплена на Eserv 3, по этому сначала подняли его.
Да и самопальный "спам-блокиратор" написан под него.
Лог инсталятора — выслал.
wikipost
ac02.12.2010 14:25
Да, по логу тоже выходит, что вы не начисто делаете установку, а с импортом из E3, и вот там при импорте списка HeloBlackList (предпоследний из импортируемых списков) и превращении его в SMTP-фильтры и происходит сбой. А "лопатит часами" относится либо к проверке импортируемых доменов либо (скорее) к поиску и импорту NT-доменов.

Попробуйте не ставить галочку импорта из E3. Те 9 пользователей, которые импортируются (по логу), можно будет и позже импортировать, есть в E4 такая функция. А больше в импортируемых файлах ничего ценного по логу не видно.
wikipost
di_line02.12.2010 16:15
Как это ничего ценного?
HeloBlackList = 189408 строк
IpBlackList.txt = 178517 строк
И что, все это богатство взять и выкинуть?

Тормозит именно на переносе *BlackList.txt.
/ac, а может все же на нормальный SQL сервер, а?..
Или, хотя бы инфу о структуре БД и SQL-запросах. Что бы можно было свое ваять./
wikipost
ac02.12.2010 16:29
А, так вот о чем ошибка "unknown" — просто таймаут

Структуру БД вам расскажет sqlite. А про таймауты при импорте такого маленького списка — беру таймаут на размышление.
wikipost
di_line02.12.2010 17:02
не плохо!
(Если еще учесть, что это длилось не менее 4 часов)

И как-бы в сторону: Хотелка еще актуальна...
wikipost
ac02.12.2010 19:26
di_line пишет: Если еще учесть, что это длилось не менее 4 часов

Ну значит у браузера такой предел терпения. На тот момент, когда вы остановили инсталлятор (импорт на тот момент еще шел, не смотря на то, что браузерный интерфейс инсталлятора уже устал ждать), большой список IpBlackList был уже полностью импортирован.

Попробуйте этот вариант: http://code.eserv.ru/Eserv427a1-setup.exe

di_line пишет: Как это ничего ценного?
HeloBlackList = 189408 строк
IpBlackList.txt = 178517 строк
И что, все это богатство взять и выкинуть?

Вы это вручную наполняли? Если нет, то ценность списков сомнительна. Уверен, что CBL+BRBL принесут вам намного больше пользы, т.к. они живые.

di_line пишет: Хотелка еще актуальна...

Какая конкретно хотелка?
wikipost
ac02.12.2010 19:30
Хотелка Индивидуальные блэклисты по ящикам? Да, в процессе. Как и всё, связанное с профилями.
wikipost
ac02.12.2010 19:33
di_line пишет: а может все же на нормальный SQL сервер, а?

А какие новые аргументы за "нормальный SQL сервер" у вас появились с момента моего ответа в той же теме, и с которым вы не стали спорить? Я с любым SQL-сервером могу неэффективно запрограммировать импорт конфига E3
wikipost
di_line02.12.2010 20:17
ac пишет: Да, в процессе. Как и всё, связанное с профилями.
Спасибо! Подпргиваю, но жду.

ac пишет: А какие новые аргументы за "нормальный SQL сервер" у вас появились с момента моего ответа в той же теме...

Так и там не был раскрыт вопрос о "распределенной" системе.
Поясню. Обслуживается почтовый домен одной из турфирм. А в этой сфере — каждый туроператор имеет свою рассылку, Моска+Питер. Плюс 5-10 специализированых рассылок, + еще кой-какие. + Почта служебная, бумашки, сканы, PDF и прочая документация. + Личная почта. Ну где-то 190-200 обращений в секунду как пиковое наблюдаю. (цифра реальная) + Валящийся из ниоткуда спам, так как EMail-ы ходят из спамерских баз туда-сюда.
Ессно, это приводит, в первую очередь, к перегрузу дисковой системы сервера. И тут, без возможности распределения нагрузки, становится все сложнее работать.
Просто по роду работы знаю с какими нагрузками (транзакций в секунду) играючи справляется выделенный SQL сервер под FireBird на дешовом, "офисном" железе с многогигабайтными БД.
Плюс, уж извините Адрей:
  1. Если сохранен весь архив форума, то можно найти мой первый вопрос к Вам о использовании SQL.
  2. Конкуренты, а я просмотрел большое количество комерческих Почтовых серверов, используют "внешний" SQL-сервер, в часности MySQL. Это позволяет создать 2-х, и более, машинную конфигурацию почтовика. Заа меньшие, замечу, деньги, чем брендовое железо.
  3. Дырявость SQLite, как и MySQL, описана даже в журнале Хакер, и использование SQLite и в Web-интерфейсе ставит этот вопрос разряд актуальных.
wikipost
ac02.12.2010 20:59
di_line пишет: Просто по роду работы знаю с какими нагрузками (транзакций в секунду) играючи справляется выделенный SQL сервер под FireBird на дешовом

Разные данные. Тот же SQLite дает в "стендовых" испытаниях сотни тысяч insert'ов в секунду (обгоняя в этом деле MySQL). Основная проблема с базами не в к-ве запросов, а во фрагментации данных на диске при длительной работе с динамическими данными. Когда реальная скорость чтения файла с диска (безо всякой обработки, просто линейное чтение) падает до 500Кб/сек, то любая БД начнет тормозить. [большой кэш в памяти и предаллокацию неперемещабельного файла оставим пока за скобками, раз уж речь о дешевых офисных конфигах, где ни памяти лишней, ни диска]
di_line пишет: Дырявость SQLite, как и MySQL, описана даже в журнале Хакер

Дырявость и производительность — разные вещи. MySQL у нас на сервере eserv.ru стоит больше 10лет, с открытым наружу портом, и никаких проблем с безопасностью это ни разу не создало. А SQLite наружу не выставляется (не умеет), а внутри Eserv он под контролем, и если там есть какие дыры, то они будут на нашей совести, а не SQLite.

Журналы это хорошо, но собственный 20-летний опыт работы с БД я тоже списывать не буду. Опять же, если слезать с SQLite, то не на MySQL, и тем более не на FireBird, а уже на что-то самодельное. Вон самодельные стат.БД, внедренные летом — те, что в DATA\stats\2010 — работают стремительно, не смотря на самую большую (из всех БД на сервере) нагрузку на запись (число записей/сек) и требование реалтайма при чтении. Ни один SQL-сервер не сможет выполнять эту узкую задачу быстрее, гарантирую. Но прежде чем делать аналогичную замену для других баз надо убедиться, что SQLite там исчерпал себя — а это, на мой взгляд, далеко не так, пространство для оптимизации еще есть.

Что касается распределения нагрузки — в SMTP и в DNS есть два замечательных средства — возможность использования более одной MX для домена, и возможность указания более одного IP для хоста... Хотя я на вашем месте начал бы с отключения сотен тысяч записей в HeloBlackList/IpBlackList (серьезное уменьшение объема чтения), понижения уровня логов (IMAP, например, по умолчанию пишет все сессии целиком — а это бывают гигабайты записи в день).
wikipost
di_line02.12.2010 21:18
ac пишет: а во фрагментации данных на диске при длительной работе с динамическими данными.
исходя из своего опыта работы с БД, это искуственно привнесенное. Уж извините, но FB с файлом БД ни делает ничего. По этому дисковой фрагментации не возникает. Логическая "фрагментация" слегкостью перекрывается индексацией данных, что резко уменьшает кол-во дисковых чтений, как и кеширование данных самим SQL-сервером. Со всеми вытекающими.

ac пишет: Что касается распределения нагрузки — в SMTP и в DNS есть два замечательных средства — возможность использования более одной MX для домена, и возможность указания более одного IP для хоста...

Вот тут-то тот же вопрос опять взлетает: — распределенная система. Пусть 2 хоста, с разными IP торчат наружу.
Как их организовать для работы под управлением Eserv4.x ?
С учетом того, что и Web-интерфейс может быть на третьем хосте.
Вопрос не настолько праздный.
wikipost
ac02.12.2010 21:27
"Дешевое офисное железо"... Вспомнилась история на эту тему, не могу удержаться от пересказа. Где-то году в 95м или 96м приходит ко мне хороший товарищ и говорит "у нас на заводе давно стоят без дела десятки компьютеров Robotron 1715, вот если бы их можно было использовать для склада...". Кто не в курсе: Robotron 1715 — это немецкое изделие времен ГДР на базе 8-разрядного процессора U880 — клоне Z80, они были довольно распространены в советских бухгалтериях второй половины 80х — я сталкивался с ними тоже, меня "премировали" возможностью работы на Роботронах в местном ВЦ за победу в областной олимпиаде по программированию году в 87м. Я, конечно, отказаться от такой сложной и в то же время ностальгической задачи не мог Поставил одно условие — программировать буду не на Роботроновом бейсике, а на Форте. Форт для CP/M (Ленинградской разработки) у меня был в виде распечатки двоичных дампов Товарищ на условие согласился, посадил человечка набить эти 8Кбайт хексов, и после нескольких исправлений Форт заработал на Роботроне. А через неделю-другую заработала и самодельная складская БД (на Роботроновых дискетах можно было уместить склад с к-вом наименований до 10тыс). При этом я не изобретал никаких особых "систем управления БД", а пользовался штатной возможностью тех старинных фортов — т.н. "блоками" — кэшируемый доступ к диску блоками по 1Кб И работало это быстрее, чем за год до того сданная (мною) заказчику сетевая складская БД для компьютерной фирмы, где основными машинами тогда были 486. В общем, когда заранее известно, что машина заведомо слабее обычного, то сразу находятся способы сделать-таки работу даже на дохлой машине, а иногда "с перепугу" даже намного эффективнее. Ведь, в конце-концов, компьютеры и в 60х годах делали что-то полезное, хотя были слабее современных микроконтроллеров площадью 5кв.мм.

Так что, не волнуйтесь, если торможение в какой-то подсистеме Eserv станет (по мере накопления данных) сильно заметно, то мы эту подсистему заменим на такую, которая будет минимум в 10 раз быстрее. Как было c IMAP'ом при переходе E3->E4.
wikipost
ac02.12.2010 21:39
di_line пишет: Логическая "фрагментация" слегкостью перекрывается индексацией данных,

Ах, если бы. С индексом, конечно, лучше, чем без него (это как раз то, что я исправил в SMTP-фильтрах для вас в указанной выше сборке . НО с ростом индекса он тоже неизбежно становится фрагментированным, потому как БД не единственный пользователь диска. Избежать фрагментации можно только если увеличивать размер БД большими кусками — с запасом на будущую запись (предаллокация). Но и это не сильно спасает, т.к., опять же, СУБД не единственный пользователь диска на сервере — пока БД читает индекс (помним про ограниченность кэша), масса процессов хотят читать что-нибудь другое и, что еще хуже, записывать что-нибудь. А каждое движение головок — 15мс... И вот уже сотня несвязанных запросов/сек (и даже не "запросов" с вычислениями, а просто операций чтения) может стать проблемой.
wikipost
ac02.12.2010 21:49
di_line пишет: Пусть 2 хоста, с разными IP торчат наружу.
Как их организовать для работы под управлением Eserv4.x ?

Поставить два Eserv'а. Некоторые клиенты уже используют такую схему.

di_line пишет: Как их организовать для работы под управлением Eserv4.x ?
С учетом того, что и Web-интерфейс может быть на третьем хосте.
Вопрос не настолько праздный.

С третьим хостом даже проще — на нем тоже поставить Eserv и форвардить туда почту, принятую и очищенную первыми двумя. Первые два синхронизировать (в этом случае) не требуется — они работают параллельно и принимают то, что каждому из них достанется (о распределении нагрузки между ними заботятся отправители, т.к. IP хоста перебираются в случайном порядке). Весь спам, все избыточные логи (95% логов — про отвергнутую почту), вся нагрузка по перебору ваших 300тыс ненужных фильтров останется на них, а третьему хосту останется работа в основном по выдаче почты из чистых и менее фрагментированных баз.
wikipost
di_line02.12.2010 22:01
ac пишет: ...СУБД не единственный пользователь диска на сервере... (и далее)
Тут я полнотью согласен с Вами. Для случая, как это организовано в текущей версии Eserva. И использовать в это случае разные шпиндели — вот так сразу и не разберешься.
И, ессно, натыкаешься на пресловутые "100 IOP-сов" указанные Вами. Разнесение информации на несколько шпинделей — позволяет обойти это.

ac пишет: Поставить два Eserv
А можно попросить тынц в доку на это место? Или где про это можно почитать?
wikipost
di_line02.12.2010 22:05
ac пишет: Robotron 1715 ГДР на базе 8-разрядного процессора U880
За это надо по 50 курвазье!
  • Прозит!
wikipost
di_line02.12.2010 22:39
ac пишет: Попробуйте этот вариант:
Не-е, ну нельзя же так откружать бедного админа. В таком кол-ве кнопок — недели 2 разбираться надо...
wikipost
ac02.12.2010 23:01
di_line пишет: ac пишет: Поставить два Eserv'а А можно попросить тынц в доку на это место? Или где про это можно почитать?

Второй Eserv настраивать точно также, как первый. Можно даже просто скопировать с диска на диск. Ничего друг о друге им знать не требуется, и никакой спец-конфигурации для этого варианта. Единственная проблема — список учетных записей: если они не из NT берутся, то каждого нового пользователя придётся добавлять в трех экземплярах — на каждом сервере... Либо поставить на первых двух Relay[ProxyMode]=1 — тогда они будут выяснять существование пользователей на указанном сервере (третьем), правда тогда это увеличит его (третьего) нагрузку. Мне кажется, что при вашем числе пользователей ручная синхронизация списков лучше, чем спец-настройка. А если пользователей много, то, когда будете добавлять первого нового пользователя после установки трех серверов — пишите, добавлю функцию автосинхронизации уч.записей.

di_line пишет: За это надо по 50 курвазье!

Интересные задачи я с удовольствием решаю бесплатно. Если время есть, конечно (это было еще до Eserv.

di_line пишет: В таком кол-ве кнопок — недели 2 разбираться надо...

Если вы уже кнопки видите, то значит импорт в новом варианте прошел успешно? Или пропустили?
wikipost
ac02.12.2010 23:06
Если вы первый раз после E3 ставите E4, то не спешите пока с установкой лишних серверов E4 очень сильно оптимизирован по сравнению с E3, в т.ч. и по файловым операциям, и велика вероятность, что проблема перегрузки уйдет сама собой.
wikipost
tbmos02.12.2010 23:22
"Обслуживается почтовый домен одной из турфирм. А в этой сфере — каждый туроператор имеет свою рассылку, Моска+Питер"
Позвольте с вами не согласится ну это очень спорный вопрос и отдельная тема,а вот если уважемый ac даст возможность автоматически возможность отписываться от списка рассылки адресатам рассылки ?! это огромная помощь админу(к стати сколько стоит sql2005 например лицензия стандарт di_line? ) а если это турфирма еще и испльзует мастер-тур с с вырузкой — помотрите нагрузки и цены..лицензирования(уже требуют лицензирования принтера!)
wikipost
di_line02.12.2010 23:29
Извините, но кроме туроператоров есть турагентские фирмы, кол-во которых немношко больше. И на любую их них, "нагрузка" от туроператоров немного больше, чем операторов.
wikipost
di_line02.12.2010 23:39
ac пишет: то значит импорт в новом варианте прошел успешно?
А то! Иначе бы опять дебоширил и немношка хулиганил.
ac пишет: E4 очень сильно оптимизирован по сравнению с E3, в т.ч. и по файловым операциям, и велика вероятность, что проблема перегрузки уйдет сама собой.
Так я, вроде бы, нормальный админ, то есть параноидальный.
По этому буду мышковать по кнопкам. А там и видно будет, из практики.
wikipost
di_line03.12.2010 15:01
Та-ак...
Ну не знаю какой это SQLite на зуб (SqliteDev381 уже у меня есть...) но! acWEB4.exeПочтовый сервер SMTPФильтры... грузить на все 100% 2 ядра компика и только и знает что свопить... 10 мин. ничего не выдал.
А там-то всего-то 350 тышь строк конвертнулось.
(Ага, внял и немношко порезал.)
wikipost
ac07.12.2010 21:38
SQLite не причем. Это загрузка таблички в браузер так тормозит. Если не через собственную консоль acWEB'а смотреть (встроенный IE), а по сети входить на 2009й порт, то может получиться быстрее на других браузерах. Но вообще для любого браузера динамическая загрузка в страницу таблицы такого размера — это сложная задача. Пагинации при просмотре таблиц в E4 нет, т.к. таблицы предполагаются обозримого размера. Самыми большими бывают списки пользователей (у нас на сервере 50тыс.), но они обычно сегментируются по доменам/проектам (или выбираются через поиск), т.е. загружается не весь. Этот список в 350тыщ при работе самого SMTP-сервера не подтормаживает его?
wikipost
di_line08.12.2010 02:54
ac пишет: Этот список в 350тыщ при работе самого SMTP-сервера не подтормаживает его?
Не-а. Почтовик еще на 3-ке сидит. А в 4-ку я пока только мышкой...
wikipost
Работает на Eserv/5.05555 (05.06.2016)