Долгое закрытие дня! Помогите.

[klassik1990]

Первый день на работе. с r-keeper 6 дело не имел ровно так же как и со SH.
Начали задавать вопросы почему r-keep начал долго закрывать дни? Раньше быстрее на много было по словам.
А у SH импорт из R-keeper даже за период в один день началась такая же проблема?
Подскажите?:(

[mnekin]

Может просто продажи в разы больше стали?
Объем данных увеличился, соответственно время пересчета и выгрузки данных сервером увеличилось

[SH]

Начали задавать вопросы почему r-keep начал долго закрывать дни? Раньше быстрее на много было по словам.
Посмотрите, куда идет бэкап. Когда запускается закрытие, вначале выполняется бэкап старого udb - если бэкап по сети, то он, действительно, может долго идти, потому что файлик большой (сами посмотрите, сколько у Вас весит). Само закрытие потом очень быстро проходит.
Можно отказаться от встроенного бэкапа и заменить его своим.


А у SH импорт из R-keeper даже за период в один день началась такая же проблема?
Это тоже может быть из-за сети.

[klassik1990]

Спасибо за помощь. Завтра посмотрю, отпишусь.

[sibgaba]

Большой размер ark6.udb.
Отсюда:
1. Большое время на создание резервной копии при закрытии дня.
2. Много времени уходит на то что бы открыть файл при импорте расхода.

Если файл действительно копируется по сети - надо попытаться от этого избавиться.

Как вариант, можно начать с чистого листа (с чистого ark6.udb) естественно сделав копию старого и отдельный ярлык для отчетов прошлого периода.

[SH]

Ну, с чистого не обязательно, а вот с начала года - вполне можно, если управляющие не возражают. А если данные накоплены за несколько лет - так можно и прошлый год оставить.
Можно еще хитрее поступить: сделать копию DB вместе с ark6.udb и делать копию endday перед закрытием - закрывать дважды, в "полную базу" и в "урезанную". Импорт в хаус делать из "урезанной", отчеты - по обстоятельствам, смотря что нужно.
Хотел так сделать в одной сети кофеен, но они решили на rk7 перейти и стало неактуальным.

[klassik1990]

Щас буду пробовать. Но сначала разберусь что где лежит. Имеется сервер 192.168.1.10 на нём висит только CardServer 7.09. Так же через него по удалёнке бухгалтера закрывают дни и делают импорт из Rk. К нему подключены три сетевых диска (т.е. это три точки по гороту с ресторанами как объяснили). Ещё есть сервер с базой 192.168.1.78 ( как я понимаю в трее висит три базы работающих к примеру RLSERVER DARVIN и HEARTS) так же 2 значка в трее с R-keeper Service Print Reirector 3.02.

---------- Добавлено в 04:17 ---------- Предыдущее сообщение было размещено в 03:26 ----------


Большой размер ark6.udb.
Отсюда:
1. Большое время на создание резервной копии при закрытии дня.
2. Много времени уходит на то что бы открыть файл при импорте расхода.

Если файл действительно копируется по сети - надо попытаться от этого избавиться.

Как вариант, можно начать с чистого листа (с чистого ark6.udb) естественно сделав копию старого и отдельный ярлык для отчетов прошлого периода.
Итого нашёл 5 баз.2685
С чистого не ариант. Так как я ещё боюсь что ли бо менять. Опыта почти нету толком:(

---------- Добавлено в 04:21 ---------- Предыдущее сообщение было размещено в 04:17 ----------


Посмотрите, куда идет бэкап. Когда запускается закрытие, вначале выполняется бэкап старого udb - если бэкап по сети, то он, действительно, может долго идти, потому что файлик большой (сами посмотрите, сколько у Вас весит). Само закрытие потом очень быстро проходит.
Можно отказаться от встроенного бэкапа и заменить его своим.


Это тоже может быть из-за сети.
Выше скрин баз. получается с двух точек передаётся через канал по инету. и третья которая находится тут тоже так же долго закрывает день. Видимо дело не в сети? Так?

[klassik1990]

2686
вот этими пятью закрытиями пользуются. базы нашёл. для каждой отдельная папочка.

[sibgaba]

Y, Z и W это у вас явно сетевые диски. Объем файлов которые на них лежат > 0,5 ГБ
Сетевые диски не в локалке, а в интете VPN или типа того...

Вот и получите...

[klassik1990]

Y, Z и W это у вас явно сетевые диски. Объем файлов которые на них лежат > 0,5 ГБ
Сетевые диски не в локалке, а в интете VPN или типа того...

Вот и получите...
Это и так понятно что они сетевые все:). Да больше, но это ему не мешала выгружаться нормльно т.е. быстро. Через впн, да.

[sibgaba]

Я не знаю "как было раньше". Вы этого тоже не видели. Верить бухам на слово - это последнее дело.

Включите логику: Программа (Закрытие дня или Транспорт - не важно) запускается на сервере в бухгалтерии. Ей нужно обновить (при закрытии) файл, который лежит на сетевом ресурсе. Соответственно нужно:
1. Скачать его с сетевого диска и загрузить в память (по сети)
2. Изменить и сохранить на сетевой диск (по сети)
3. Если резервная копия так же делается на сетевой диск, то еще и старую версию сохранить по сети.

Итого перекинуть туда-сюда по VPN каналу 750 мегов (для диска Z). Попробуйте просто проводником его скопировать на локальную машину, замерьте время и умножайте его на 3. Сколько получится? Меньше этого времени не получится ну ни как!!!

Варианты как все это ускорить безусловно есть. Можно базы подрезать, можно организовать теневую синхронизацию (через DropBox или скриптами), можно для бухов сделать параллельную копию ark6.udb. Тогда на точке буду закрывать в свою базу (локально) бухи в свою (тоже локально).

Но все это требует понимания того как Кипер хранит данные и какие файлы за что отвечают. Иначе можно дров наломать...

[klassik1990]

Я не знаю "как было раньше". Вы этого тоже не видели. Верить бухам на слово - это последнее дело.

Включите логику: Программа (Закрытие дня или Транспорт - не важно) запускается на сервере в бухгалтерии. Ей нужно обновить (при закрытии) файл, который лежит на сетевом ресурсе. Соответственно нужно:
1. Скачать его с сетевого диска и загрузить в память (по сети)
2. Изменить и сохранить на сетевой диск (по сети)
3. Если резервная копия так же делается на сетевой диск, то еще и старую версию сохранить по сети.

Итого перекинуть туда-сюда по VPN каналу 750 мегов (для диска Z). Попробуйте просто проводником его скопировать на локальную машину, замерьте время и умножайте его на 3. Сколько получится? Меньше этого времени не получится ну ни как!!!

Варианты как все это ускорить безусловно есть. Можно базы подрезать, можно организовать теневую синхронизацию (через DropBox или скриптами), можно для бухов сделать параллельную копию ark6.udb. Тогда на точке буду закрывать в свою базу (локально) бухи в свою (тоже локально).

Но все это требует понимания того как Кипер хранит данные и какие файлы за что отвечают. Иначе можно дров наломать...
Я думал он не скачиает его,а сразуперезаписывает уже на сервере его.( и ни что ничего не выкачивает туда сюда).
Вот если бы понимал бы, так как дело не имел с ним. А разбираться без бывшего сис. админа так сказать не сказачно.
С чего хотя бы начь, не поскажите?

[sibgaba]

Я думал он не скачиает его,а сразуперезаписывает уже на сервере его.( и ни что ничего не выкачивает туда сюда).
Вот если бы понимал бы, так как дело не имел с ним. А разбираться без бывшего сис. админа так сказать не сказачно.
:facepalm:
Тут то вопрос не в области конкретного ПО (Кипера), а в общих принципах работы OS и файловой системы...


С чего хотя бы начь, не поскажите?

Для начала нужно понять, кто работает с БД. Тут может быть 3 варианта:

1. Все словари и справочники (меню персонал и т.п.) редактируются бухами на сервере. На точке с редактором и отчетами не работают.
2. Все словари и справочники (меню персонал и т.п.) редактируются Менеджерами на точках. Бухам база нужна только для того что бы взять из нее расход.
3. Работают и там и там по полной программе.

Если 1 то перенести базы на сервер, а на точках переписать пути с локальных на сетевые (на БД лежащую на сервере). Это немного замедлит загрузку кассового сервера, но не критично.

Если 2 - то организовать теневое копирование. Например ресторан работает до 12 ночи. Соответственно в 1 ночи там делают закрытие дня. Соответственно ночью, допустим в 5 утра, на сервере запускается скрипт, который делает копию БД на сервер. У SH все пути переписываем на локальную БД. В итоге, когда в 9 приходят бухи у них локально на сервере лежат актуальные базу.

Если 3 - то организовать синхронизацию. Например через DropBox. Будут небольшие временнЫе лаги (в одном месте поменяли меню, в другое место оно попадет с небольшой задержкой), но не особо критично.

[klassik1990]

:facepalm:
Тут то вопрос не в области конкретного ПО (Кипера), а в общих принципах работы OS и файловой системы...



Для начала нужно понять, кто работает с БД. Тут может быть 3 варианта:

1. Все словари и справочники (меню персонал и т.п.) редактируются бухами на сервере. На точке с редактором и отчетами не работают.
2. Все словари и справочники (меню персонал и т.п.) редактируются Менеджерами на точках. Бухам база нужна только для того что бы взять из нее расход.
3. Работают и там и там по полной программе.

Если 1 то перенести базы на сервер, а на точках переписать пути с локальных на сетевые (на БД лежащую на сервере). Это немного замедлит загрузку кассового сервера, но не критично.

Если 2 - то организовать теневое копирование. Например ресторан работает до 12 ночи. Соответственно в 1 ночи там делают закрытие дня. Соответственно ночью, допустим в 5 утра, на сервере запускается скрипт, который делает копию БД на сервер. У SH все пути переписываем на локальную БД. В итоге, когда в 9 приходят бухи у них локально на сервере лежат актуальные базу.

Если 3 - то организовать синхронизацию. Например через DropBox. Будут небольшие временнЫе лаги (в одном месте поменяли меню, в другое место оно попадет с небольшой задержкой), но не особо критично.
Учусь ещё :)
Есть два бухгалтер они работают только с 1с.
Есть бухгалтер работает с rk and sh т.е. отчёты и всё что прилагается(пока не знаю все обязанности её) у неё удалёнка с учёткой на сервере 192.168.1.10 в ней собственно и редактирует.
На точках только печатаю чеки.
И по какому варианту пробовать?
заранее спасибо.

[sibgaba]

Если

На точках только печатаю чеки.
т.е. только с фронтом работают, то тогда №1

[klassik1990]

Хорошо, попробую. А теперь попробую не накосячить в процессе((.