Форум OlegON > Программы и оборудование для автоматизации торговли > Кассовые программы > УКМ-4

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

28.03.2024 23:14


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 смотря какой сервер...
мускул одним процессом работает, а лимит на память для процесса никто не отменял...
Часовой пояс GMT +3, время: 23:14.

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