[ОТВЕТИТЬ]
03.12.2013 23:36
baggio
 
жрет памяти от 10ГБ :)
04.12.2013 08:14
Exact
 
Однажды у одного клиента замечал проблему с установкой лицензии потом написал батничек вот такого плана находящийся в каталоге с установленной "айяйкой"
@echo off
net stop iikotomcat
del /q /a *.dat
net start iikotomcat
А памяти при работе 1 клиента + 1 касса жрёт 1,5Гб SQL ну и 500Мб примерно Apache Tomcat. Необходимо учитывать при планировании развертывания сервера, а в целом интерфейс дружественный, с точки зрения администратора кафе "аяйяйКа" неплохой софт.Но я особо не тестировал
04.12.2013 08:56
OlegON
 
А 10Гб это на сервере, надеюсь? Может, просто выделили столько для MS SQL? Клиент сам тонкий?
04.12.2013 13:53
baggio
 
там суть следующяя...
при старте глючный tomcat портированный под винду... кэширует по ходу целиком базу SQL... что из этого происходит я думаю объяснять не надо...
у меня волосы шевелились когда я видел потребление памяти...
короче... ставьте не меннее 16ГБ... иначе швах...
10.12.2013 16:41
vsyartsev
 
Цитата:
при старте глючный tomcat портированный под винду... кэширует по ходу целиком базу SQL... что из этого происходит я думаю объяснять не надо...
у меня волосы шевелились когда я видел потребление памяти...
короче... ставьте не меннее 16ГБ... иначе швах...
На самом деле, томкат жрет память не потому что глючный, а чтобы пересчет быстро происходил. В память забирается, конечно же, не вся база, а только открытый период: так специально сделано, чтобы обеспечить быстрый пересчет документов и транзакций (это нужно для работы задним числом в реальном времени).

Для обычного ресторана рекомендованный объем памяти на сервере 4—8Гб, процессор - core i5. На серверах такой конфигурации вполне комфортно работает большинство пользователей iiko.

Разумеется, если мы говорим о сетевом решении, надо понимать, что центральная БД содержит полные копии всех БД всех ресторанов. Поэтому, ресурсы, требуемые для работы iikoChain, прямо пропорционально зависят от кол-ва ресторанов (для iikoChain с двумя ресторанами вполне запросто потребуется 10-16Гб оперативной памяти на сервере).

Есть две тонкости:

1) Если держать открытый период больше двух месяцев, то памяти нужно будет еще больше, и клиенты не всегда это понимают. Лучше изначально ориентировать клиента, что работать "задним числом" можно будет только в переделах 2-3 месяцев.

2) MS SQL, если его не админить, со временем начинает потреблять больше памяти. Поэтому, нужно его периодически обслуживать: прогонять скрипты оптимизации индексов, чистить логи и т.д.
19.12.2013 00:53
baggio
 
блин.. вот не в обиду но чё оно стоко памяти ест?
и самое главное стартуем минут 15...
может это не нормально?
19.12.2013 00:58
iiko_russia
 
Вы уже задавали этот вопрос в другой ветке форума, и мы вам там ответили :) Потребление памяти системой iiko

Но могу и продублировать здесь:

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

Для обычного ресторана рекомендованный объем памяти на сервере 4—8Гб, процессор - core i5. На серверах такой конфигурации вполне комфортно работает большинство пользователей iiko.

Разумеется, если мы говорим о сетевом решении, надо понимать, что центральная БД содержит полные копии всех БД всех ресторанов. Поэтому, ресурсы, требуемые для работы iikoChain, прямо пропорционально зависят от кол-ва ресторанов (для iikoChain с двумя ресторанами вполне запросто потребуется 10-16Гб оперативной памяти на сервере).

Есть две тонкости:

1) Если держать открытый период больше двух месяцев, то памяти нужно будет еще больше, и клиенты не всегда это понимают. Лучше изначально ориентировать клиента, что работать "задним числом" можно будет только в пределах 2-3 месяцев.

2) MS SQL, если его не админить, со временем начинает потреблять больше памяти. Поэтому, нужно его периодически обслуживать: прогонять скрипты оптимизации индексов, чистить логи и т.д.
19.12.2013 01:13
baggio
 
не не...
это я читал... не поймите не правильно...
я к тому зачем?
т.е такое потребление чем то обусловленно ...
ведь гогда разрабатавалось решение память так доступна не была...
зачем в глобальном смысле....?
19.12.2013 09:58
OlegON
 
Так база жрет или iiko? Просто для базы, например, это нормально...
19.12.2013 10:59
baggio
 
ты понимаешь какая штука... база он скуль можно подрезать использовать и 1гб оперативки... т.е. он будет работать на том что дадено... просто поменьше кэшируя... это относится не только к скулю... но и к майскулю и к ораклу... дело в другом... разрабы должны были чем то руководствоваться когда открытый периуд целиком при старте пихают в том... т.е. для этого была какаято причина... возможно это увеличивает быстродействие... возможно надежность... но в любом случаем разрабы должны были это как то аргументировать... типа потому что... вот и я хочу услышать что по этому поводу говорили и говорят разрабы...
19.12.2013 11:07
termit68ru
 
Цитата:
baggio ты понимаешь какая штука... база он скуль можно подрезать использовать и 1гб оперативки... т.е. он будет работать на том что дадено... просто поменьше кэшируя...
Ты чет завернул.Он будет не работать,а "работать"
19.12.2013 13:45
baggio
 
вот тут я точно не понял что имелось ввиду?
ты хочешь сказать что 10гб база не будет работать на 4гб озу? или на 3? или на 2?
19.12.2013 17:00
iiko_russia
 
Такое потребление памяти именно тем, что написал Василий, и обусловлено - возможностью быстро обрабатывать данные в открытом периоде (то есть том, в котором можно проводить изменения и перепроводить документы). Например, чтобы если надо техкарту поменять, то при этом мгновенно остатки пересчитались и все документы перепровелись. Что касается соотношения стоимости ОЗУ и затрат на ведение учета, так даже тогда, когда мы начали только продукт разрабатывать, потери от невозможности вести оперативный учет были уже существенно выше, чем стоимость железа. Хотите уменьшить память - уменьшите открытый период учета.
21.12.2013 14:49
baggio
 
не не... вы меня правда простите... но я постараюсь с вас не слезьть...
пойдём другим путем...

1. я так понимаю что при старте том считывает данные из скуля открытого периуда...
2. Затем при изменении документа задним числом всё это быстро пересчитывается в раме тома...
3. Вопрос в какой момент происходит сброс данных в скуль? и что будет если данные в томе изменились в скуль отвалился и не записал изменения?

я всё таки структуру пытаюсь понять... изввените за назойливойсть... тут нет цели уличить в излишней зависимости от пвмяти... просто я уверен что это сделано не спроста... а вот те ответы которые я получаю лично меня пока не убедили что всё это затевается ради открытого периуда...
23.12.2013 12:52
vsyartsev
 
Цитата:
1. я так понимаю что при старте том считывает данные из скуля открытого периуда...
2. Затем при изменении документа задним числом всё это быстро пересчитывается в раме тома...
Вы все верно написали.

Цитата:
3. Вопрос в какой момент происходит сброс данных в скуль? и что будет если данные в томе изменились в скуль отвалился и не записал изменения?
Сбрасывается в фоновом режиме. То есть, сервер записывает в БД изменения постоянно, но ему нет необходимости ждать завершения записи для продолжения работы —это делается в отдельных потоках, параллельно. В реальности задержки в записи почти нет (понятно, что чем больше база, тем больше задержка).

Если SQL отваливается, это, конечно же, аварийная ситуация. В этом случае система переходит в автономный режим, о чем предупреждает пользователя (Внимание! Недоступна БД SQL, возможна потеря данных!) и работает так в течение часа. Если в течение часа связь с SQL не восстановилась, работа останавливается. Если восстановилась, просто накатываются изменения.

В 99% случаев SQL стоит на той же машине, что и Tomcat, поэтому такая ситуация возникает у клиентов крайне редко (обычно из-за ошибок в настройке MS SQL или Windows).
Опции темы


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

 

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