Очередная подстава

Обычно я терпимо отношусь к использованию ОС Windows в самых различных областях, видимо потому, что мне нечасто приходится иметь с ней дело. Последние события, напрямую связанные с использованием Windows 2003 в качестве серверной операционки на производительном железе, заставили меня основательно пересмотреть эту оценку, причем не в ее пользу. Но обо всем по порядку.

Один из серверов БД на работе стал вести себя нестабильно (диагностика показала аппаратные проблемы с RAID-контроллером), и было решено временно перебросить с него базу данных на мощный компьютер, пока решается вопрос с заменой сбойных комплектующих. База хранилась в PostgreSQL, сервер работал под Linux RHEL4, а на компьютере-приемнике стояла «Windows 2003 R2 Enterprise Edition». Уповая на кроссплатформенность PostgreSQL, я не придал этому значения, и как показала практика – напрасно. После установки win-версии PostgreSQL-сервера был запущен импорт дампа базы данных, и через час «pg_restore» вывалился с ошибкой:

pg_restore: [archiver (db)] error returned by PQputCopyData:
could not send data to server: No buffer space available
(WSAENOBUFS 0x00002747/10055)

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

На мой запрос Google выдал, что это довольно распространенная проблема Windows-систем (в том числе, и серверных), не связанная со спецификой Postgre. Это меня не утешило, - я был в цейтноте.

Официальная статья в «Microsoft Knowledge Base» и заметка на сайте «1С» немного пролили свет на ситуацию и казалось, проблема должна быть решена - но приведенные инструкции не работали. Увеличение диапазона пользовательских портов не дало эффекта. Манипуляции с уменьшением значения «TCP_WAIT» в параметрах TCP/IP с отключением всего, что только возможно (антивирусы, файерволы) и последующей перезагрузкой результата не принесли.

Дальнейшие исследования показали, что все упирается в размер дампа – если размер базы превышает примерно 10Гб, сетевая подсистема не справляется при импорте с большим количеством клиентских подключений к службе. На данный момент я не нашел приемлемого решения. Может быть, никому просто не приходит в голову хранить на Windows-серверах базы размером по 12-13Гб? Машина класса Hi-End с аппаратным RAID-контроллером, быстрыми винчестерами и 4Гб ОЗУ с Windows на борту оказалась «в пролете». Стоящая рядом Linux-машина (CentOS i386, обычные SATA-винчестеры и 2Гб ОЗУ) переварила дамп без проблем.

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

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