На какой странице мастера установки он долго что-то делает?

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

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

E4-setup.log пришлите, пожалуйста, на support@eserv.ru.

Да, по логу тоже выходит, что вы не начисто делаете установку, а с импортом из E3, и вот там при импорте списка HeloBlackList (предпоследний из импортируемых списков) и превращении его в SMTP-фильтры и происходит сбой. А "лопатит часами" относится либо к проверке импортируемых доменов либо (скорее) к поиску и импорту NT-доменов.

Попробуйте не ставить галочку импорта из E3. Те 9 пользователей, которые импортируются (по логу), можно будет и позже импортировать, есть в E4 такая функция. А больше в импортируемых файлах ничего ценного по логу не видно.

А, так вот о чем ошибка "unknown" — просто таймаут

Структуру БД вам расскажет sqlite. А про таймауты при импорте такого маленького списка — беру таймаут на размышление.

di_line пишет: Если еще учесть, что это длилось не менее 4 часов

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

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

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

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

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

Какая конкретно хотелка?

di_line пишет: а может все же на нормальный SQL сервер, а?

А какие новые аргументы за "нормальный SQL сервер" у вас появились с момента моего ответа в той же теме, и с которым вы не стали спорить? Я с любым SQL-сервером могу неэффективно запрограммировать импорт конфига E3

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, например, по умолчанию пишет все сессии целиком — а это бывают гигабайты записи в день).

"Дешевое офисное железо"... Вспомнилась история на эту тему, не могу удержаться от пересказа. Где-то году в 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.

di_line пишет: Пусть 2 хоста, с разными IP торчат наружу.
Как их организовать для работы под управлением Eserv4.x ?

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

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

С третьим хостом даже проще — на нем тоже поставить Eserv и форвардить туда почту, принятую и очищенную первыми двумя. Первые два синхронизировать (в этом случае) не требуется — они работают параллельно и принимают то, что каждому из них достанется (о распределении нагрузки между ними заботятся отправители, т.к. IP хоста перебираются в случайном порядке). Весь спам, все избыточные логи (95% логов — про отвергнутую почту), вся нагрузка по перебору ваших 300тыс ненужных фильтров останется на них, а третьему хосту останется работа в основном по выдаче почты из чистых и менее фрагментированных баз.

di_line пишет: ac пишет: Поставить два Eserv'а А можно попросить тынц в доку на это место? Или где про это можно почитать?

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

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

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

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

Если вы уже кнопки видите, то значит импорт в новом варианте прошел успешно? Или пропустили?

SQLite не причем. Это загрузка таблички в браузер так тормозит. Если не через собственную консоль acWEB'а смотреть (встроенный IE), а по сети входить на 2009й порт, то может получиться быстрее на других браузерах. Но вообще для любого браузера динамическая загрузка в страницу таблицы такого размера — это сложная задача. Пагинации при просмотре таблиц в E4 нет, т.к. таблицы предполагаются обозримого размера. Самыми большими бывают списки пользователей (у нас на сервере 50тыс.), но они обычно сегментируются по доменам/проектам (или выбираются через поиск), т.е. загружается не весь. Этот список в 350тыщ при работе самого SMTP-сервера не подтормаживает его?