powered by simpleCommunicator - 2.0.37     © 2025 Programmizd 02
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Глюк Cache с оперативкой или это норма?
17 сообщений из 42, страница 2 из 2
Глюк Cache с оперативкой или это норма?
    #39507361
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Глюк_КашеА это прямо необходимость такая иметь одновременно открытых в памяти 395000 объектов (все открываются и не закрываются ни разу !) ?О-О-О, вы хоть и ответили "да", но не объяснили, почему. Возможно, вы просто не знали, что открытые объекты дорого стоят, дороже, чем те же данные, уложенные в локальный массив, да и он, бывает, того...

Вы хоть и не просите помощи, а "делитесь", но большинству из нас малоинтересны такие результаты, так как мы знаем, как извлечь из Cache максимум, "если её правильно готовить".
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507365
Фотография DAiMor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я бы кстати предложил посмотреть на варианты, хранения базы целиком в памяти, конечно зависит от объема базы. Но возможно и достаточно было бы ограничится буфером глобалов. Задача оптимизации тут конечно вполне себе интересная, и решаемая, в таких случаях можно производительность на порядки улучшать при применении разных средств. И конечно тут уже зависит от ограничений, возможности горизонтального и вертикального массштабирования.

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

Многозадачность, очень хороший вариант оптимизации. При том, что в некоторых случаях можно задействовать и дополнительные машины для этого.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507406
Фотография П.С.М.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хм, а ТС'у уже давали совет, прочитать хоть какую-нибудь книжку по синтаксису используемого им языка? Или еще нет?

Дабы не возникали вопросы вида:
Почему могу дать имя aaa(1.001) и не могу дать имя aaa(1.Data) или aaa(1."Data")
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507435
Ptn
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Почитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

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

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

На кой то черт копировать таблицу с диска в локальные переменные непонятной структуры, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс, и не зная что локальные массивы после примерно 1000узлов начинают уступать глобалас, фулсканом, через открытие объекта когда можно написать ОДИН MERGE ... Нет, не пригодится.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507446
О-О-О
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
DAiMorО-О-ОЯ просто поделился. Помощи не просил.Зря вы так, для этого форумы и нужны по сути. Никогда нельзя быть уверенными что выбрали единственно верную стратегию. Когда процессы занимают продолжительное время все есть варианты которые могут его ускорить. И будут появлятся новые, при появлении например новых видов оборудования.
Вы например решили свою задачу таким способом, другие решали другим способом. Варианты можно сравнивать и выбирать лучшую стратегию.


Я прощу прощения, если кого обидел.
Хотел в конце добавить смайлик, но он не добавился.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507463
О-О-О
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
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Гбайт сек. То есть даже сравнивать бесполезно.

Писать же код в котором нужно что то анализировать (часть данных загрузить и анализировать их между собою), а что то не нужно, это ОЧЕНЬ усложняет код и постоянно нужно держать в голове, какие сейчас части проанализированы. Получается путаница и никакого удовольствия от программирования. Если есть ресурс по железу, а он и не такой уж и большой требуется, то зачем создавать лишние проблемы?
.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507465
О-О-О
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
PtnПочитал, посмотрел пример "кода", рассуждения об оперативке ... мдя....

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

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

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

MERGE скопировать то можно, а вот вытащить из него из оперативки ничего не получается. Как кусок камня. Он вроде бы и есть, а толку для анализа ноль.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507472
О-О-О
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ptn, ожидая когда возникнет ошибка STORAGE из-за ограничения памяти на один процесс,

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

Если полазить по настройкам Каше, то ОЧЕНЬ можно СУЩЕСТВЕННО увеличить быстродействие и отзывчивость системы. То есть каше можно настроить под экономичный, под стандартные и под высоконагруженный проект.
Я же говорю, что Каше очень хорошая БД, она эластичная, и легко выполняет все нужды для программирования.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507476
О-О-О
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Под Одновременно имеется ввиду, что одновременно запускается команда Job Для 30 процессов, а не фоновая работа 30 процессов.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507505
Фотография DAiMor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
О-О-О,

о каком постоянном чтении с диска речь, почитайте про буфер глобалов
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507515
Глюк_Каше
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
О-О-О,
авторЕсли 60 млн записей перемножить на 20 запросов получим 1 мрд обращений к жесткому диску. Начиная с этого места Ваш расчет никуда не годится. Обращаясь к СУБД данные проходят кэш диска "как железного" устройства, кэш операционной системы, где буферизируются операции ввода вывода, кэш самой СУБД - данные, что лежат в памяти. Судя по описанию, Вам один раз нужно будет прочесть все данные в ОЗУ (то есть они туда точно попадут). Но физических чтений с диска будет намного меньше...
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507627
О-О-О
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Глюк_Каше,

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

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

Вот что получилось
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
Считывание данных с 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 сек

Код привожу ниже, чтобы не говорили, что код не оптимизирован и избыточен.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
	
        // Это чтение данных непосредственно из Глобала (с 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
	}



.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507741
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я не читал внимательно весь топик, но после вот этого
О-О-ОaNew=$System.OBJ.OpenId(BDAnaliz,(i))

говорить о какой-то оптимизации бессмысленно. Объекты - это стильно, модно, молодежно, но если вам нужна массовая обработка данных, постарайтесь избежать их использования. Оптимальный баланс поддерживаемости кода и скорости - sql, но если уж хотите экстрима, то можно и на глобалах писать.
Дальше, глобалы тоже бывают разные. Есть просто глобалы, есть глобалы замапленные на CACHETEMP или process-private глобалы. У них разные настройки кэширования, глобалы CACHETEMP и process-private будут по максиму использовать буфер глобалов. Локальные переменные же используют память процесса, причем большие объемы этой памяти ранние версии Каше обрабатывали очень плохо, из-за чего cachetemp/process-private выигрывали по скорости. Ну и так, как это все-таки глобалы, на них можно натягивать классы и таблицы. Т.е. вы можете смержить глобал с диска в process-private и дальше работать с ним, как с таблицей, но по сути, в памяти.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507823
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Блок А.Н.говорить о какой-то оптимизации бессмысленно
В который раз убеждаюсь в непотопляемости Cache: и 30-ю процессами её не уложить, и базой данных в локальном массиве (эдак на гигабайт) не удивить. Если "На М можно запрограммировать даже ветер в голове" (© А.Шуревский), то на COS с его объектами и пр. - тайфун или торнадо.

Начиная с версии 2010.1, Cache стала быстрее работать с локальными массивами, чем с глобалами, даже закешированными. Выигрыш конечно зависит от задачи, и не всегда его легко оценить. Последний раз, когда мне удалось это сделать, он был в несколько раз. Могу освежить подробности, если это кому-то интересно. Массив был на 1000000 узлов, ЕМНИП.
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507982
Partisan M
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Alexey MaslovВ который раз убеждаюсь в непотопляемости Cache: и 30-ю процессами её не уложить, и базой данных в локальном массиве (эдак на гигабайт) не удивить. Если "На М можно запрограммировать даже ветер в голове" (

Вот именно. Для программирования ветра в голове хорошо подходит, для остального не очень. Автору вопроса лучше бы перейти на нормальную базу, а не возиться с Cache. Чем раньше, тем меньше будет потрачено зря времени. А то пользователей мало (причём, как можно сообразить, это неспроста) и от тех, что есть вместо поддержки мы тут видим восхваление Cache методом выдачи недостатков за достоинства..
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507989
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Partisan M,

насколько я понимаю, в этом случае Каше используется для решения аналитических задач, и "нормальная база" тут явно не потянет. Я бы понял, если бы вы посоветовали что-то из математического арсенала или языки программирования общего назначения (для которых, мне кажется, у ТС слабовата подготовка), но реляционная субд тут как-то не очень (да и Каше используется не в качестве реляционной СУБД).
...
Рейтинг: 0 / 0
Глюк Cache с оперативкой или это норма?
    #39507991
Фотография DAiMor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Partisan Mперейти на нормальную базуУважаемый, а что по вашему мнению нормальная база?
Мое мнение такого, если СУБД справляется с поставленной задачей, то в чем могут быть проблемы?
Непопулярность не причина в том что от нее нужно отказыватся.
Во всех СУБД если свои сильные и слабые стороны, и в некоторых случаях Caché конечно нет смысла использовать, а в других она подходит лучше.

И данный форум существует не для того чтобы его посетителям говорили, что Caché нельзя пользоваться. А помогать им в работе с ним. Если кого то волнует вопрос выбора СУБД, для этого есть другой форум.
...
Рейтинг: 0 / 0
17 сообщений из 42, страница 2 из 2
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / Глюк Cache с оперативкой или это норма?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]