Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Caché Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
 Re: Глюк Cache с оперативкой или это норма?  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1415
Глюк_Каше
А это прямо необходимость такая иметь одновременно открытых в памяти 395000 объектов (все открываются и не закрываются ни разу !) ?
О-О-О, вы хоть и ответили "да", но не объяснили, почему. Возможно, вы просто не знали, что открытые объекты дорого стоят, дороже, чем те же данные, уложенные в локальный массив, да и он, бывает, того...

Вы хоть и не просите помощи, а "делитесь", но большинству из нас малоинтересны такие результаты, так как мы знаем, как извлечь из Cache максимум, "если её правильно готовить".
18 авг 17, 10:50    [20733445]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2356
Я бы кстати предложил посмотреть на варианты, хранения базы целиком в памяти, конечно зависит от объема базы. Но возможно и достаточно было бы ограничится буфером глобалов. Задача оптимизации тут конечно вполне себе интересная, и решаемая, в таких случаях можно производительность на порядки улучшать при применении разных средств. И конечно тут уже зависит от ограничений, возможности горизонтального и вертикального массштабирования.

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

Многозадачность, очень хороший вариант оптимизации. При том, что в некоторых случаях можно задействовать и дополнительные машины для этого.
18 авг 17, 10:57    [20733462]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
П.С.М.
Member

Откуда: Из СССР
Сообщений: 376
Хм, а ТС'у уже давали совет, прочитать хоть какую-нибудь книжку по синтаксису используемого им языка? Или еще нет?

Дабы не возникали вопросы вида:
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")
18 авг 17, 11:50    [20733684]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Ptn
Guest
Почитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

Спасибо что проинформировали нас.

О-О-О
Может кому пригодится для оптимизации.


На кой то черт копировать таблицу с диска в локальные переменные непонятной структуры, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс, и не зная что локальные массивы после примерно 1000узлов начинают уступать глобалас, фулсканом, через открытие объекта когда можно написать ОДИН MERGE ... Нет, не пригодится.
18 авг 17, 12:05    [20733778]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
DAiMor
О-О-О
Я просто поделился. Помощи не просил.
Зря вы так, для этого форумы и нужны по сути. Никогда нельзя быть уверенными что выбрали единственно верную стратегию. Когда процессы занимают продолжительное время все есть варианты которые могут его ускорить. И будут появлятся новые, при появлении например новых видов оборудования.
Вы например решили свою задачу таким способом, другие решали другим способом. Варианты можно сравнивать и выбирать лучшую стратегию.



Я прощу прощения, если кого обидел.
Хотел в конце добавить смайлик, но он не добавился.
18 авг 17, 12:10    [20733808]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
DAiMor
Я бы кстати предложил посмотреть на варианты, хранения базы целиком в памяти, конечно зависит от объема базы. Но возможно и достаточно было бы ограничится буфером глобалов. Задача оптимизации тут конечно вполне себе интересная, и решаемая, в таких случаях можно производительность на порядки улучшать при применении разных средств. И конечно тут уже зависит от ограничений, возможности горизонтального и вертикального массштабирования.

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

Многозадачность, очень хороший вариант оптимизации. При том, что в некоторых случаях можно задействовать и дополнительные машины для этого.



Давайте посчитаем.
395000 строк и 154 столбца. В сумме около 60,5 млн записей.
Каждая запись участвует в перекрестном сравнении как минимум 3-4 раза и это навскидку. Кроме того эти записи сравниваются между собою. Я прикидывал. Каждая ячейка из этого массива участвует в коде от 12 до 24 раз.
Если 60 млн записей перемножить на 20 запросов получим 1 мрд обращений к жесткому диску. Выборка с SSD диска около 7500 (40Мб с 4кб блоками запросов в сек (смешанный поток). Итого получаем 1 млд/10000~100'000 сек. Даже если 10'000 это уже 3 часа.
Я помню В своё время делал код по анализу с жесткого диска (ССД). Так тогда он потратил 3 часа и проанализировал всего 8%.
С тер пор я пытаюсь перетащить данные в оперативку. Скорость оперативки 35Гбайт сек. То есть даже сравнивать бесполезно.

Писать же код в котором нужно что то анализировать (часть данных загрузить и анализировать их между собою), а что то не нужно, это ОЧЕНЬ усложняет код и постоянно нужно держать в голове, какие сейчас части проанализированы. Получается путаница и никакого удовольствия от программирования. Если есть ресурс по железу, а он и не такой уж и большой требуется, то зачем создавать лишние проблемы?
.
18 авг 17, 12:23    [20733856]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Ptn
Почитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

Спасибо что проинформировали нас.

О-О-О
Может кому пригодится для оптимизации.


На кой то черт копировать таблицу с диска в локальные переменные непонятной структуры, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс, и не зная что локальные массивы после примерно 1000узлов начинают уступать глобалас, фулсканом, через открытие объекта когда можно написать ОДИН MERGE ... Нет, не пригодится.


MERGE скопировать то можно, а вот вытащить из него из оперативки ничего не получается. Как кусок камня. Он вроде бы и есть, а толку для анализа ноль.
18 авг 17, 12:25    [20733862]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Ptn
, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс,


Это легко настраивается в настройках Каше.
Да, по умолчанию там стоит около 256 мб и еще там стоит кучу узких месть
К примеру вы не сможите ОДНОВРЕМЕННО запустить 30 фоновых процессов, так как Каше просто ляжет. и таких мелочей много. НО!!!

Если полазить по настройкам Каше, то ОЧЕНЬ можно СУЩЕСТВЕННО увеличить быстродействие и отзывчивость системы. То есть каше можно настроить под экономичный, под стандартные и под высоконагруженный проект.
Я же говорю, что Каше очень хорошая БД, она эластичная, и легко выполняет все нужды для программирования.
18 авг 17, 12:31    [20733881]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Под Одновременно имеется ввиду, что одновременно запускается команда Job Для 30 процессов, а не фоновая работа 30 процессов.
18 авг 17, 12:33    [20733892]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2356
О-О-О,

о каком постоянном чтении с диска речь, почитайте про буфер глобалов
18 авг 17, 13:09    [20734031]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Глюк_Каше
Guest
О-О-О,
автор
Если 60 млн записей перемножить на 20 запросов получим 1 мрд обращений к жесткому диску.
Начиная с этого места Ваш расчет никуда не годится. Обращаясь к СУБД данные проходят кэш диска "как железного" устройства, кэш операционной системы, где буферизируются операции ввода вывода, кэш самой СУБД - данные, что лежат в памяти. Судя по описанию, Вам один раз нужно будет прочесть все данные в ОЗУ (то есть они туда точно попадут). Но физических чтений с диска будет намного меньше...
18 авг 17, 13:35    [20734109]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
О-О-О
Member

Откуда: Нижний Новгород
Сообщений: 170
Глюк_Каше,

Дабы внести ясность я сделал следующее
Я посчитал сумму одной переменной во всех 395000 строк.
Сперва тупо обращаясь к Таблице (глобалу)

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

Вот что получилось
Считывание данных с SSD. SumMacd=-1003.739   Время=10.979169s Доступно 9863.3 Мб из 986340 возможных
 
  1 из 40 по 10'000.  Доступно RAM: 9715.4
  2 из 40 по 10'000.  Доступно RAM: 9567.6
  3 из 40 по 10'000.  Доступно RAM: 9419.7
  4 из 40 по 10'000.  Доступно RAM: 9271.9
  5 из 40 по 10'000.  Доступно RAM: 9124
  6 из 40 по 10'000.  Доступно RAM: 8976.2
  7 из 40 по 10'000.  Доступно RAM: 8828.3
  8 из 40 по 10'000.  Доступно RAM: 8680.5
  9 из 40 по 10'000.  Доступно RAM: 8532.6
  10 из 40 по 10'000.  Доступно RAM: 8384.8
  11 из 40 по 10'000.  Доступно RAM: 8236.9
  12 из 40 по 10'000.  Доступно RAM: 8089.1
  13 из 40 по 10'000.  Доступно RAM: 7941.3
  14 из 40 по 10'000.  Доступно RAM: 7793.4
  15 из 40 по 10'000.  Доступно RAM: 7645.6
  16 из 40 по 10'000.  Доступно RAM: 7497.7
  17 из 40 по 10'000.  Доступно RAM: 7349.9
  18 из 40 по 10'000.  Доступно RAM: 7202
  19 из 40 по 10'000.  Доступно RAM: 7054.2
  20 из 40 по 10'000.  Доступно RAM: 6906.3
  21 из 40 по 10'000.  Доступно RAM: 6758.5
  22 из 40 по 10'000.  Доступно RAM: 6610.6
  23 из 40 по 10'000.  Доступно RAM: 6462.8
  24 из 40 по 10'000.  Доступно RAM: 6315
  25 из 40 по 10'000.  Доступно RAM: 6167.1
  26 из 40 по 10'000.  Доступно RAM: 6019.3
  27 из 40 по 10'000.  Доступно RAM: 5871.4
  28 из 40 по 10'000.  Доступно RAM: 5723.6
  29 из 40 по 10'000.  Доступно RAM: 5575.7
  30 из 40 по 10'000.  Доступно RAM: 5427.9
  31 из 40 по 10'000.  Доступно RAM: 5280
  32 из 40 по 10'000.  Доступно RAM: 5132.2
  33 из 40 по 10'000.  Доступно RAM: 4984.3
  34 из 40 по 10'000.  Доступно RAM: 4836.5
  35 из 40 по 10'000.  Доступно RAM: 4688.7
  36 из 40 по 10'000.  Доступно RAM: 4540.8
  37 из 40 по 10'000.  Доступно RAM: 4393
  38 из 40 по 10'000.  Доступно RAM: 4245.1
  39 из 40 по 10'000.  Доступно RAM: 4097.3
 Строк=394650  Время=161.117946s Доступно 4028.5 Мб из 986340 возможных
 
 
2) Считывание данных из RAM.  SumMacd=-1003.739   Время=.686559s Доступно 4028.5 Мб из 986340 возможных
 


С SSD диска время составило 10.98 сек
Из Оперативки 0.69 сек

Код привожу ниже, чтобы не говорили, что код не оптимизирован и избыточен.
	
        // Это чтение данных непосредственно из Глобала (с SSD диска)
        Set EndID=$Order(@BDAnalizDDD@(""),-1) 
	Set SumMacd=0
	For i=1:1:EndID
	{
		Set aaaNew=$System.OBJ.OpenId(BDAnaliz,(i))
		Set SumMacd=SumMacd+aaaNew.MAXXX
	}

        // Это чтение данных из Оперативки.
	Set TStart=$ZH
	Set SumMacd=0
	Set em="MACXXX"
	For i=1:1:EndID
	{
		Set zma1="aaaMA=aaa("_i_","_""""_em_""""_")",@zma1
		Set SumMacd=SumMacd+aaaMA
	}


.
18 авг 17, 16:07    [20734739]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Блок А.Н.
Member

Откуда: Новосибирск
Сообщений: 3529
Я не читал внимательно весь топик, но после вот этого
О-О-О
aNew=$System.OBJ.OpenId(BDAnaliz,(i))

говорить о какой-то оптимизации бессмысленно. Объекты - это стильно, модно, молодежно, но если вам нужна массовая обработка данных, постарайтесь избежать их использования. Оптимальный баланс поддерживаемости кода и скорости - sql, но если уж хотите экстрима, то можно и на глобалах писать.
Дальше, глобалы тоже бывают разные. Есть просто глобалы, есть глобалы замапленные на CACHETEMP или process-private глобалы. У них разные настройки кэширования, глобалы CACHETEMP и process-private будут по максиму использовать буфер глобалов. Локальные переменные же используют память процесса, причем большие объемы этой памяти ранние версии Каше обрабатывали очень плохо, из-за чего cachetemp/process-private выигрывали по скорости. Ну и так, как это все-таки глобалы, на них можно натягивать классы и таблицы. Т.е. вы можете смержить глобал с диска в process-private и дальше работать с ним, как с таблицей, но по сути, в памяти.
18 авг 17, 20:30    [20735312]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Alexey Maslov
Member

Откуда: СПб
Сообщений: 1415
Блок А.Н.
говорить о какой-то оптимизации бессмысленно

В который раз убеждаюсь в непотопляемости Cache: и 30-ю процессами её не уложить, и базой данных в локальном массиве (эдак на гигабайт) не удивить. Если "На М можно запрограммировать даже ветер в голове" (© А.Шуревский), то на COS с его объектами и пр. - тайфун или торнадо.

Начиная с версии 2010.1, Cache стала быстрее работать с локальными массивами, чем с глобалами, даже закешированными. Выигрыш конечно зависит от задачи, и не всегда его легко оценить. Последний раз, когда мне удалось это сделать, он был в несколько раз. Могу освежить подробности, если это кому-то интересно. Массив был на 1000000 узлов, ЕМНИП.
19 авг 17, 12:38    [20735786]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Partisan M
Member

Откуда:
Сообщений: 1166
Alexey Maslov
В который раз убеждаюсь в непотопляемости Cache: и 30-ю процессами её не уложить, и базой данных в локальном массиве (эдак на гигабайт) не удивить. Если "На М можно запрограммировать даже ветер в голове" (


Вот именно. Для программирования ветра в голове хорошо подходит, для остального не очень. Автору вопроса лучше бы перейти на нормальную базу, а не возиться с Cache. Чем раньше, тем меньше будет потрачено зря времени. А то пользователей мало (причём, как можно сообразить, это неспроста) и от тех, что есть вместо поддержки мы тут видим восхваление Cache методом выдачи недостатков за достоинства..
20 авг 17, 11:14    [20736741]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
Блок А.Н.
Member

Откуда: Новосибирск
Сообщений: 3529
Partisan M,

насколько я понимаю, в этом случае Каше используется для решения аналитических задач, и "нормальная база" тут явно не потянет. Я бы понял, если бы вы посоветовали что-то из математического арсенала или языки программирования общего назначения (для которых, мне кажется, у ТС слабовата подготовка), но реляционная субд тут как-то не очень (да и Каше используется не в качестве реляционной СУБД).
20 авг 17, 11:51    [20736771]     Ответить | Цитировать Сообщить модератору
 Re: Глюк Cache с оперативкой или это норма?  [new]
DAiMor
Member

Откуда: Volzhsky -> Moscow -> CZ, Brno
Сообщений: 2356
Partisan M
перейти на нормальную базу
Уважаемый, а что по вашему мнению нормальная база?
Мое мнение такого, если СУБД справляется с поставленной задачей, то в чем могут быть проблемы?
Непопулярность не причина в том что от нее нужно отказыватся.
Во всех СУБД если свои сильные и слабые стороны, и в некоторых случаях Caché конечно нет смысла использовать, а в других она подходит лучше.

И данный форум существует не для того чтобы его посетителям говорили, что Caché нельзя пользоваться. А помогать им в работе с ним. Если кого то волнует вопрос выбора СУБД, для этого есть другой форум.
20 авг 17, 11:52    [20736773]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Caché Ответить