[ОТВЕТИТЬ]
10.03.2013 16:02
Eugin_S
 
Мы сейчас подключаем все кассы напрямую к СГО, без промежуточных серверов. Около 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 на новом сервере
10.03.2013 17:59
OlegON
 
Варя с кучей нюансов по доступу к СХД. А "проблемы" и "не выгрузилось", это подразумеваются какие-то ошибки? Чего-то не хватило? Хотелось бы более ясной картины, чем "начались проблемы и поставили более мощный сервер".
11.03.2013 03:03
Eugin_S
 
У нас на VMWare большинство серверов из продакшена, так что с нюансами мы знакомы.
Сервер просто не успевал обрабатывать поступившие данные и выгружать их через конвертер (CSV). К тому же произошел какой-то сбой - сервер завис намертво, данные накопились, что тоже усугубило проблему.
На диск в это время нагрузка была небольшая, на память стандартная - то что позволено в my.ini, процессор был загружен больше обычного, но не на максимуме.

Я сейчас не хочу расследовать случившуюся ситуацию, просто хочу понять на будущее, какие ресурсы нужно выделить серверу для нормальной работы с запасом.
11.03.2013 09:04
OlegON
 
Так в том и дело, что никто не скажет, например, сколько у вас дисконтов, карточек, какое влияние виртуалки, скорость дисков и т.п. Необходимо исследовать причины сбоя, slow-query.log смотреть, оценить ситуацию в комплексе, а потом уже смотреть, где узкое место. Помимо ежедневной работы бывают и разовые всплески, которые тоже надо учитывать. Т.е. если тормозит, надо проверить оптимальность работы софта, а потом уже задирать железку.
Оптимизация базы - Страница 2
11.03.2013 09:46
Little
 
Проблема в том, что большое количество конверторов не может быть запущено одновременно! Вариант, либо разнести их, либо руками разгребать! Либо использовать рабочую схему с промежуточными серверами магазинов.
11.03.2013 12:12
Eugin_S
 
Цитата:
Little Проблема в том, что большое количество конверторов не может быть запущено одновременно! Вариант, либо разнести их, либо руками разгребать! Либо использовать рабочую схему с промежуточными серверами магазинов.
А почему нельзя? У нас 3 конвертеров импорта и 3 конвертеров экспорта, и они до этого случая нормально работали.
11.03.2013 13:19
Little
 
Это как это 35 магов на каждом по кассовой линейке, на каждую линейку по 3 конвертера итого должно быть 105, может конечно я устарел и теперь можно обойтись меньшим количеством, но раньше с таким сталкивался и конверторы захлебывались...
11.03.2013 14:34
Eugin_S
 
Цитата:
Little Проблема в том, что большое количество конверторов не может быть запущено одновременно! Вариант, либо разнести их, либо руками разгребать! Либо использовать рабочую схему с промежуточными серверами магазинов.
Цитата:
Little Это как это 35 магов на каждом по кассовой линейке, на каждую линейку по 3 конвертера итого должно быть 105, может конечно я устарел и теперь можно обойтись меньшим количеством, но раньше с таким сталкивался и конверторы захлебывались...
А зачем по 3? У нас импорт и экспорт. Оперсводку не используем.
11.03.2013 15:15
Little
 
Цитата:
Eugin_S А зачем по 3? У нас импорт и экспорт. Оперсводку не используем.
Тогда проще, но не на много.. Как только ККМ реплицировали данные на сервер, он их пытается скинуть в конвертер, дальше насколько помню. УКМ смотрит, запущен конвертер или нет и дает тайм аут остальным процессам. После тайм аута все начинается заново. С каждым разом время ожидания повторения выгрузки растет. В свое время так и не нашел механизма заставить нормально проходить выгрузку, приходилось руками пинать.
12.03.2013 16:13
Belivern
 
Ну, не знаю, я бы предложил использовать какие-то иные конвертеры - например Импорт/Экспорт 4(MySQL). Думаю, он пошустрее бы работал.
12.03.2013 16:27
Mtirt
 
А он умеет работать с Супермагом?
12.03.2013 16:30
Belivern
 
Цитата:
Mtirt А он умеет работать с Супермагом?
Ну....

:connie_mini_worrier*122
12.03.2013 16:59
Onesoft
 
Цитата:
Eugin_S innodb_buffer_pool_size=14000 на новом сервере
гм.. это меньше 14 кБайт. Ничего не путаешь? У нас значение этой настройки на 32 ГБайт оперативы:
innodb_buffer_pool_size=22G

Ещё нюанс. Когда подключаешь кассу к СГО напрямую, она сливает на СГО всю историю продаж, что есть в ней (поскольку СГО ещё не получал от неё данных о продажах - только от её СМа, а это разные вещи), переписывая имеющиеся данные. Операция эта выполняется в одной транзакции, буфера памяти под которую может не хватить. Попытка впихнуть невпихуемое будет сопровождаться прерыванием операции импорта данных на СГО с откатом транзакции (а это зачастую выполняется ещё дольше, чем сам импорт) с попыткой повтора данных действий. В логах СГО будут соответствующие записи. Если это происходит, то удвой в my.ini значение переменной max_binlog_cache_size, у нас оно равно 8GB.

Если транзакции рвутся из-за проблем со связью, то поможет импорт данных с касс с разбиением на несколько транзакций. Для этого создаётся новый домен репликации данных, например, "Чеки ждут", который нереплицируется никуда и в который переносятся все чековые таблицы из домена "Чеки". Затем постерпенно из домена "Чеки ждут" одна за одной перетаскиваются таблицы обратно в домен "Чеки", следя за процессами репликации данных. Таблицы trm_out_receipt_header, trm_out_receipt_footer, trm_out_moneyoperation*, trm_out_shift*, trm_out_login, trm_out_logout должны переноситься в самую последнюю очередь и все вместе!!! чтобы "committer"-процессы сервера обработали все пришедшие чеки корректно.

Если имеется проблема с прокачкой данных через конвертеры экспорта, то на время выполнения импорта данных с касс конвертеры экспорта надо поставить в "Паузу", а по окончании загрузки данных узнай для последних закрытых смен их последние id и последние id их чеков:

Код:
SELECT h.cash_id,MAX(h.id)AS last_receipt_header,MAX(so.id)AS last_shift_closed_id
FROM trm_out_receipt_header h
INNER JOIN trm_out_shift_open so ON so.cash_id=h.cash_id AND so.id=h.shift_open
INNER JOIN trm_out_shift_close sc ON sc.cash_id=so.cash_id AND sc.id=so.id
-- WHERE cash_id IN(<cash_id1>,<cash_id2>,...,<cash_idN>)
GROUP BY h.cash_id;
Полученные значения подставь в таблицу cnv_unload_state - это журнал выгруженных конвертерами экспорта смен и чеков. Затем запусти конвертеры экспорта в автоматическом режиме. Они начнут выгружать только чеки для открытых и следующих смен, а для старых закрытых - уже не будут. Останется только выгрузить интересующие закрытые смены вручную.
14.03.2013 10:50
Eugin_S
 
Да, прошу прощенья, у меня:

innodb_buffer_pool_size=10000M
14.03.2013 11:39
Eugin_S
 
Цитата:
Onesoft Ещё нюанс. Когда подключаешь кассу к СГО напрямую, она сливает на СГО всю историю продаж, что есть в ней (поскольку СГО ещё не получал от неё данных о продажах - только от её СМа, а это разные вещи), переписывая имеющиеся данные.
У нас кассы с самого начала подключены к серверу, и СМов не было никогда. Так что такой ситуации не возникает.

Цитата:
Onesoft Если транзакции рвутся из-за проблем со связью, то поможет импорт данных с касс с разбиением на несколько транзакций. Для этого создаётся новый домен репликации данных, например, "Чеки ждут", который нереплицируется никуда и в который переносятся все чековые таблицы из домена "Чеки". Затем постерпенно из домена "Чеки ждут" одна за одной перетаскиваются таблицы обратно в домен "Чеки", следя за процессами репликации данных. Таблицы trm_out_receipt_header, trm_out_receipt_footer, trm_out_moneyoperation*, trm_out_shift*, trm_out_login, trm_out_logout должны переноситься в самую последнюю очередь и все вместе!!! чтобы "committer"-процессы сервера обработали все пришедшие чеки корректно.
Не совсем понял про домены данных, зачем они нужны, но из за проблем со связью транзакции не рвутся.

Цитата:
Onesoft Если имеется проблема с прокачкой данных через конвертеры экспорта, то на время выполнения импорта данных с касс конвертеры экспорта надо поставить в "Паузу", а по окончании загрузки данных узнай для последних закрытых смен их последние id и последние id их чеков:

Код:
SELECT h.cash_id,MAX(h.id)AS last_receipt_header,MAX(so.id)AS last_shift_closed_id
FROM trm_out_receipt_header h
INNER JOIN trm_out_shift_open so ON so.cash_id=h.cash_id AND so.id=h.shift_open
INNER JOIN trm_out_shift_close sc ON sc.cash_id=so.cash_id AND sc.id=so.id
-- WHERE cash_id IN(<cash_id1>,<cash_id2>,...,<cash_idN>)
GROUP BY h.cash_id;
Полученные значения подставь в таблицу cnv_unload_state - это журнал выгруженных конвертерами экспорта смен и чеков. Затем запусти конвертеры экспорта в автоматическом режиме. Они начнут выгружать только чеки для открытых и следующих смен, а для старых закрытых - уже не будут. Останется только выгрузить интересующие закрытые смены вручную.
Вот за это спасибо. Попробуем.


Мы выяснили что скорее всего у нас была проблема из-за антивируса, он блочил сетевые соединения с кассами. Но тему я создавал для того чтобы понять, достаточные ли ресурсы мы выделили серверу для работы с таким количеством касс.
14.03.2013 12:06
Onesoft
 
Цитата:
Eugin_S Не совсем понял про домены данных, зачем они нужны, но из за проблем со связью транзакции не рвутся.
Домены нужны для группировки нескольких таблиц по какому-нибудь функциональному признаку для того, чтобы обеспечить их репликацию в требуемом направлении. Например, домен "Параметры" реплицирует настройки кассовой линейки с сервера на кассы, а домен "Чеки" реплицирует чеки с касс на серверы. Но можно включить репликацию чеков и с сервера на кассы - теоретически это должно привести к тому, что на всех кассах будут чеки со всех касс (но делать этого не рекомендую, года три назад что-то подобное у нас произошло при подключении к СГО давно работающих СМов, в результате чего произошло смешение доменов => дикий ахтунг).


Цитата:
Eugin_S Мы выяснили что скорее всего у нас была проблема из-за антивируса, он блочил сетевые соединения с кассами.
Ещё антивирусы любят мацать файлы БД - тогда мускул просто падает с соответствующей ошибкой в err файле. Кстати, С+ не рекомендует ставить антивирусы на серверах УКМ 4.0, по этим причинам в частности и по причине отъёма ресурсов вообще. Не ставим антивирус на сервера и мы - антивирусы и так стоят на всех остальных компах и серверах вокруг УКМ, а доступ на сервера УКМ извне и наружу закрыт.

Цитата:
Eugin_S Но тему я создавал для того чтобы понять, достаточные ли ресурсы мы выделили серверу для работы с таким количеством касс.
Это можно понять, анализируя использование этих самых ресурсов Task Managerом и Resource Monitorом. Главное - чтобы хватало ОЗУ и процесс mysqld вообще никак не трогал pagefile.sys. Ну и чтобы очередь обращения к дискам (с БД и с папкой временных файлов MySQL) не поднималась выше 80% Highest Active Time. Ну и ещё наблюдая за processlist в БД сервера.
15.03.2013 13:06
avdeevalexey
 
34 магазина, 105 посов, товаров 80000, клиентов 100000, конвертеры импор и экспорт 4
Core I7-2600, 3,4Ггц, 12 ГБ RAM
Win 2008 SP2 32
innodb_buffer_pool_size=1200M

пока полет нормальный
15.03.2013 16:51
Onesoft
 
Цитата:
avdeevalexey Core I7-2600, 3,4Ггц, 12 ГБ RAM
Win 2008 SP2 32
То есть фактически используется только 3 гига RAM.. Прикольно..
15.03.2013 22:23
Dim
 
смотря какой сервер...
Цитата:
Максимум (32-разрядные компьютеры): 4 ГБ (для Windows Server 2008 Standard) либо 64 ГБ (для Windows Server 2008 Enterprise или Windows Server 2008 Datacenter)
Максимум (64-разрядные компьютеры): 32 ГБ (для Windows Server 2008 Standard) либо 2 ТБ (для Windows Server 2008 Enterprise, Windows Server 2008 Datacenter или Windows Server 2008 для компьютеров на базе процессоров Itanium)
15.03.2013 22:37
OlegON
 
Цитата:
Dim смотря какой сервер...
мускул одним процессом работает, а лимит на память для процесса никто не отменял...
15.03.2013 22:41
Dim
 
речь была о том, что сервер 32 бита, а стоит 12 Гб
15.03.2013 22:46
OlegON
 
Цитата:
Dim речь была о том, что сервер 32 бита, а стоит 12 Гб
Ну да, хоть 120Гб, только мускулу ты отдашь максимум 3Гб. Бо х32.
16.03.2013 03:22
Eugin_S
 
Я когда переносил на новый сервер и увеличивал память - заменил бинарники на x64. Проблем вообще никаких не возникло.
16.03.2013 12:27
Onesoft
 
Цитата:
Eugin_S Я когда переносил на новый сервер и увеличивал память - заменил бинарники на x64. Проблем вообще никаких не возникло.
Они и не должны были возникнуть. Более того, даже если бинарники будут линуксовыми (в линуксе ессесно) - тоже проблем не возникнет.
18.03.2013 08:38
avdeevalexey
 
Цитата:
Onesoft То есть фактически используется только 3 гига RAM.. Прикольно..
Прошу прощения, не уточнил...Win 2008 Enterprise

Добавлено через 4 минуты 35 секунд
Пока тормозов нет - пусть работает, а потом все равно на никсы переведу
Опции темы


Часовой пояс GMT +3, время: 03:33.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.