Помогите разобраться с проблемой. Ensemble 2010 установлена на машинах примерно одинаковой конфигурации, настройки Ensemble одинаковы на тестовых машинах. Одна машина с Win2003, другая с Win7, третья с WinXP.
В базе данных имеется тестовая глобаль ^A размером около 800Мб. Первоначально в настройках Ensemble было выделено 1,5Гб для 8К баз данных. На первом уровне глобали порядка 850,000 элементов.
Запускаем цикл:
s i="" f c=1:1:850000 s i=$O(^A(i)) q:i=""
На Win7 при первом запуске цикл отрабратывает примерно за ~25 секунд, последующие запуски - менее 1 секунды.
На Win2003 чуть быстрее (сам компьютер чуть быстрее).
На WinXP, что первый, что последующие запуски - более 10 минут. Компьютер чуть быстрее, чем под управлением Win7.
Настройки памяти Ensemble никак не смогли ускорить процесс.
Вопрос. Это проблема XP? Возможно как-то настроить XP, чтобы увеличить производительность? Возможно как-то настроить Ensemble, чтобы увеличить производительность?
На всех тестовых компьютерах - 32-битные ОС.
Заметил еще такую особенность, при запуске вычислений, использующих глобаль ^A, на XP процесс "отъедает" память вплоть до 1Гб (если верить Windows Task Manager) и столько же "съедает" WriteDaemon (идет запись в глобаль после вычислений), на Win2007 и Win7 Windows Task Manager показывает не более 4Мб на каше процессы. Соответственно, учитывая вычисления, загрузка процессоров Win2007 и Win7 близка к 100%, но на XP загрузка процессора 0-10%.

Памяти точно не выделено больше, чем физической (на компе 4Гб, хотя XP видит только 3+Гб), но перепроверю, когда будет доступ к системе, спасибо за наводку. Но пробовал от 100Мб до 2Гб выделять для Ensemble - без результатно.
Оптимизацию для фоновых процессов не делал, потому что на Win7 ее тоже нет.
В cconsole.log никаких подозрительных записей (вернее, после старта Ensemble вообще никаких).

Насчет памяти в Win7 Task Manager вы правы - Ensemble "ест" столько же.

Зато на Win7 обнаружил:
02/22-10:56:27:474 (0) 1 Failed to allocate 2036MB shared memory using large pages. Switching to small pages.
02/22-10:56:27:482 (0) 1 Failed to allocate 2032MB shared memory: 1920MB global buffers, 20MB routine buffers
02/22-10:56:27:482 (0) 1 Allocated 1536MB shared memory: 1440MB global buffers, 18MB routine buffers

Временно нету доступа к XP системе, поэтому проделал несколько экспериментов на Win7.
Пробовал уменьшать настройки памяти, но больших страниц так и не получил. Но это действительно не суть.
В случае, когда для баз данных отведено места меньше, чем объем глобали ^A, то глобаль не кэшируется, и каждый запуск цикла длится около 25 секунд. В случае, когда объем выделенный для баз данных вмещает целиком ^A, каждый последующий запуск цикла длится менее секунды, что логично.
Проблема в том, что вчера на XP системе мне не удалось уложиться даже в 10 минут при различных настройках памяти в Ensemble. Пытаюсь понять - это проблема конкретной системы или все таки ОС.
Буду создавать еще одну систему для теста, но, может быть, кто-то уже тестировал различные ОС и видел или не видел отличий в производительности? Насколько я помню в Cache 5 и WinXP подобных проблем не замечал. Более новые версии Cache/Ensemble в WinXP ранее не запускал.

Блок А.Н.,
проблема, что есть три Win32: 2003, 7 и XP, первые две работают так, как по логике и положена, а вот XP конкретно тормозит.
Для нормальной работы приложения достаточно 1,2Гб для Cache, соответственно, Win32 должно хватать (что я и вижу на двух системах).

Блок А.Н.Николай Жохов(консультант ИС) сильно ругал механизм выделения памяти в винде.
Кстати, попробуйте выделить память для каше при перезагрузке.

Что вы имеете ввиду? Просто перезапустить Windows?
Блок А.Н.Возможно, из-за фрагментации не может выделить большой кусок. И своп-файл сделайте размером с физическую память.
Сейчас он такой и есть.

servit А.В. ,
Какова ситуация с автоматически выделяемой памятью вместо ручного выделения?

Разницу заметить сложно, потому что ооочень долго.
servitКакова у Вас сейчас Эффективность кэша / Cache Efficiency ?

Импорт данных из CSV файлов, затем сканирование глобали (в процессе - тот цикл, что я писал), в данный момент значение 220.
servitPS: у меня на XP c 2Гб физической памяти глобал с 10млн. узлов обходится за 3.6 сек. и создаётся <1мин.
PPS: Determine Number of Global Buffers
У меня на Win7 все тоже быстро. Но на XP клиента все очень медленно - по крайней мере в 30 раз медленнее при сопоставимом железе.

servitПричина может быть:
в железе;


Может быть, но копирование файла cache.dat занимает полторы минуты, а проход по первому уровню глобали (глобаль занимает практически весь объем базы данных) идет 40 минут - мягко говоря - странно.
servitв настройках ОС или сопутствующих программах, например включённом антивирусе, другой СУБД;


Грешил на антивирус, но добавил все папки каше в исключения оного - не помогло. Никаких процессов занимающих много памяти или использующих процессор хотя бы на 1% на исследуемой системе не было.
servitв настройках СУБД.


Настройки аналогичные похожей системе на Win7, где все летает. Настройки памяти для баз данных изменялись в широких пределах (включая дефолтные) - разницы замечено не было.
servitДля начала попробуйте на другой физической или виртуальной машине с XP повторить эксперимент с настройками ОС/СУБД по-умолчанию.

Пришел к такому же выводу. Буду пробовать.
servitPS: существует ещё одна возможная причина проблемы:
Цитата из документацииWhen you defer login you must call the license login method immediately. A process that has not performed a license login pauses after every 1000 lines of Caché ObjectScript code.
По скорости работы очень похоже именно на подобное поведение. Но клиент-сервер - один компьютер, делаю запуск через терминал, терминал настроен для запуска только по паролю. Одинаковые проблемы при входе через zen-приложение и аутентификации в нем.
Но посмотрю в этом направлении повнимательнее.

Версия полнофункциональная.
Мониторинг посмотрю. Какие диапазоны значений приемлимы, какие нет?