Подключение касс напрямую к СГО, конфигурация сервера : УКМ-4

Мы сейчас подключаем все кассы напрямую к СГО, без промежуточных серверов. Около 160 касс в 35 магазинах. У нас очень хорошие каналы связи и проблемы со связью проблемы бывают крайне редко.

Дело в том что мы столкнулись с ситуацией, когда сервер не справился с количеством данных о покупках. 7-8 марта был бум продаж (на некоторых магазинах продажи превысили продажи за НГ) в где-то в 4 часа ночи с 7го на 8ое число начались проблемы с сервером, не выгрузилось большее число данных. 8го числа в срочном порядке был поднят новый сервер на 64-битной архитектуре и с большем количеством памяти, но продажи с касс все равно заливались и выгружались долгое время.

Хотелось бы узнать, использует ли кто-нибудь еще такую схему работы, сколько касс и какая конфигурация сервера.
У нас: старый сервер - Win2008 (32bit), 8CPU, 4Gb RAM, все это на VMWare, жесткий диск на СХД, подключеном по оптике. Новый сервер - Win2008R2, 8CPU, 16Gb RAM, так же на VMWare, жеский диск на том же СХД.

innodb_buffer_pool_size=14000 на новом сервере

Варя с кучей нюансов по доступу к СХД. А "проблемы" и "не выгрузилось", это подразумеваются какие-то ошибки? Чего-то не хватило? Хотелось бы более ясной картины, чем "начались проблемы и поставили более мощный сервер".

У нас на VMWare большинство серверов из продакшена, так что с нюансами мы знакомы.
Сервер просто не успевал обрабатывать поступившие данные и выгружать их через конвертер (CSV). К тому же произошел какой-то сбой - сервер завис намертво, данные накопились, что тоже усугубило проблему.
На диск в это время нагрузка была небольшая, на память стандартная - то что позволено в my.ini, процессор был загружен больше обычного, но не на максимуме.

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

Так в том и дело, что никто не скажет, например, сколько у вас дисконтов, карточек, какое влияние виртуалки, скорость дисков и т.п. Необходимо исследовать причины сбоя, slow-query.log смотреть, оценить ситуацию в комплексе, а потом уже смотреть, где узкое место. Помимо ежедневной работы бывают и разовые всплески, которые тоже надо учитывать. Т.е. если тормозит, надо проверить оптимальность работы софта, а потом уже задирать железку.
Оптимизация базы - Страница 2

Проблема в том, что большое количество конверторов не может быть запущено одновременно! Вариант, либо разнести их, либо руками разгребать! Либо использовать рабочую схему с промежуточными серверами магазинов.

А почему нельзя? У нас 3 конвертеров импорта и 3 конвертеров экспорта, и они до этого случая нормально работали.

Это как это 35 магов на каждом по кассовой линейке, на каждую линейку по 3 конвертера итого должно быть 105, может конечно я устарел и теперь можно обойтись меньшим количеством, но раньше с таким сталкивался и конверторы захлебывались...

А зачем по 3? У нас импорт и экспорт. Оперсводку не используем.

Тогда проще, но не на много.. Как только ККМ реплицировали данные на сервер, он их пытается скинуть в конвертер, дальше насколько помню. УКМ смотрит, запущен конвертер или нет и дает тайм аут остальным процессам. После тайм аута все начинается заново. С каждым разом время ожидания повторения выгрузки растет. В свое время так и не нашел механизма заставить нормально проходить выгрузку, приходилось руками пинать.

Ну, не знаю, я бы предложил использовать какие-то иные конвертеры - например Импорт/Экспорт 4(MySQL). Думаю, он пошустрее бы работал.