Доброго времени суток.
Помогите разобраться.
Дано: база на Access 2010. База разделена (данные+клиент). На каком-то этапе база стала медленно работать - поиск в основной форме стал работать 20 секунд (а это наиболее востребованная функция).
Механизм поиска и ошибки в коде не принципиальны так-как:
При запуске на локальном компе под Windows 10 (i5+6RAM) поиск занимает от 1 до 3 сек
При запуске на локальном компе под Windows Server (i3+6RAM) поиск занимает 2 до 5 сек
При запуске на сервере (двухпроцессорный Xeon+16RAM) поиск занимает от 8 до 20 (иногда и более) сек.

Подскажите в какую сторону копать. Спасибо

upd: Один из разработчиков утверждает, что в процессе поиска у него подключается второе ядро (это машина с i3 процессором)

На других машинах я этого не увидел

Аллюр Д.1. Посмотрите размер файла с данными - если файл заметно распух, то это может стать причиной "тормозов". Сделайте копию, на всякий случай, и выполните сжатие базы
Под рукой нет Access'а 2010, поэтому точное название пункта не скажу, но там в настройках есть галка - Сжимать при закрытии
2. Если сжатие и уменьшение размера не привело к ожидаемому повышению скорости поиска, по посмотрите наличие индексов в полях, по которым выполнятся поиск

Предполагаю, что поиск выполняется штатными средствами Access'а, а не бэйсиковским Find или проверкой recordset'а в цикле

Первые два пункта мимо. Сжатие есть, индексы есть. Более того - по условиям задачки у нас база одинаковая на 3 машины

Поиск выполняется путём изменения параметра в запросе - источнике данных подчинённой формы.

Да куда уж подробнее?
У меня на локальном компе всё летает. (1)
У второго программиста на локальном компе всё летает. (2)
Запускам локально на сервере - всё тормозит. (3)

Дело не в программе - она одинаковая!
Дело не в серверной винде - на 2ой машине поставили серверную винду.
Дело в Ксеонах?

Аллюр Д.Safich,

Теперь телепатам надо угадать конфигурации этих компьютеров?

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

1. что Вы подразумеваете под запуском на локальном компе? Оба файла - с программой и с данными, находятся на этом компьютере?
2. Какой размер файла с данными? На сколько он уменьшается после сжатия?
Если открыть файл с программой, то при закрытии сожмётся только файл с программой, а файл с данными так и останется несжатым
3. была версия про индексы - Вы сами проверяли их наличие или верите на слово разработчику?
4. слова i5, i3, xeon не значат ничего! Например, у нас, i3, купленные в начале этого года, заметно быстрее, чем i5, которые были куплены пару лет назад. А старенький сервер на Xeon'е, думаю, будет в 10 раз медленнее, чем эти, двухгодичной давности, i5

Конфиги описаны в первом посте, от вопросов не отбрыкиваюсь, просто наверно пропустили, читайте внимательнее.

1) В обычной работе пользователи (10-15 человек) работают по сети (VPN+RDP), поэтому первое что было исключено - скорость работы сети или глюки RDP(или VPN). И файл с базой и файл с клиентом физически находятся на той машине, с которой всё запускается. При этом к этому компьютеру подключена клавиатура, мышь, монитор и человек, в том числе и к серверу.
2) База данных. Примерно 300 мегабайт. Сжимается незначительно, автосжатие стоит, перед тестом сжималась принудительно.
3) Базу местами писал и я - индексы там есть, но поскольку в той форме запрос объединяет кучу таблиц, проверить всё долго.
4) У меня i5, купленный 5 лет назад. i3 - 2-3 года назад, ксеонов 2: один 3ёхлетний (E3-1220 v2), другой 4летний (просто Xeon - 2 процессора).

Ещё раз, клиент и база абсолютно идентичны, запускаются одинаково. Но на серверных машинах база тормозит.

Аллюр Д.Вы невероятно упорны

Допустим, что выполняется на одной и той же версии Access, с одинаковыми сервис-паками и всеми обновлениями Офиса и Виндоуз.
Вы не указали разрядности ОС, ну допустим, они все 64-разрядные.
Скорее всего, влияние дефрагментированности файла с данными вряд ли так сильно сказывается на производительности Access'а, но я бы выполнил дефрагментацию, чтобы привести все файлы "к одному знаменателю"
Дальше запустил бы поиск и посмотрел в Диспетчере задач нагрузку на процессор и использование памяти, заодно может быть выяснилось, что какая-то сторонняя задача нагружает процессор.
Дальше, запустил бы программу тестирования производительности железа (кажется у Windows 7 есть и какая-то всроенная тестилка) и может быть выясилось бы, что произволительность железа находится в таких же пропорциях как и скорость поиска в базе

Поскольку проверять индексы Вы категоричеси не ходите, то можно проверить косвенно план выполнения запроса - сохранить самый медленный запрос и поверить по времени, столько же будет выполняться или больше/меньше. Сделайте несколько запусков, чтобы усреднить влияние кэширования. Если не путаю, то Access по-разному строит планы выполнения для сохранённых запросов и для запросов формируемых "на лету"

Вы игнорирете не только мои вопросы, товарищ Ы написал про условия - используются символы подстановки?
И вообще, есть разница в скорости выполнения запроса на всех трёх компах, если нет условий отбора?

Наверное, завтра выйдут на работу настоящие сильные экстрасенсы и они махом всё решат

Упорствуете тут только вы)
Допустим индексы кривые, допустим базу не сжимали, допустим используются символы подстановки...
Это НЕ ВАЖНО, так-как базы ОДИНАКОВЫЕ! Файлы с данными тоже ОДИНАКОВЫЕ (Ctrl+C, Ctrl+V)

Винда конечно x64, другие уже наверно никто не ставит, офис тоже одинаковый.
7ой винды, если вы внимательно посмотрите тред, нет ни на одной из машин.

Посмотреть в диспетчере задач - смотрели. Ничего лишнего, только Access. Собственно и вопрос насчёт второго ядра вылез отсюда (из диспетчера). На сервере (двухпроцессорном) поиск загружает 1 ядро на 100% (общая загрузка 15%).
На компьютере под номером 2 - тоже с серверной виндой, но с i3 процессором, вроде загружается несколько ядер.

Разница в выполнении запроса "без условий" такая же.

Сообщение тов. "Ы" не было проигнорировано, а частично отвечено моим следующим постом. Тем более оно тоже "мимо": предположение, что виновата сеть или блокировки ошибочно... а предложение "переделать на SQL сервер" слишком ресурсозатратно

ROISafichНа каком-то этапе база стала медленно работать - поиск в основной форме стал работать 20 секунд (а это наиболее востребованная функция).
Поиск в форме это гадкое зло.
РекордСет вас спасет.
С уважением.
Поиск - условие в "источнике данных формы" = рекордсет

Predeclared1-я машина: Win XP (32) на 2-х ядерном Athlon-е, 2 гига озу.
2-я машина: Win Server 2008 R2 (64) на 2-х процессорном Xeon, 4 гига озу.

1-я машина заметно шустрее, даже на глаз.
В причинах не разбирался, ибо по барабану. :)
То есть даже не пытались? Жаль, проблема-то, судя по всем, идентичная.

vmagВаш сервер отрабатывает на ура только как файловый сервер (на все вопросы дает быстрые ответы),
по сему видно, что на это он и заточен, когда программа на нем работает локально, то акцесу уже приходится
делить ресурсы (приоритет, память, процессор) со всем тем, что на нем запущено + если вы запускаете еще
и исходник проекта - то антивирус еще и проверяет весь код vba (c касперским mdb точно заметно тормозит
по сравнению с mde). Попробуйте сделать простой эксперимент - выдерните после работы сервак из LAN,
перезагрузите, подождите минут 5 и потом подергайте локально базу - каков будет результат ?
Не совсем понял. Сервер "на ура" не отрабатывает никак (ни по сети, ни локально).
Есть боевой сервер (тот что E3-1220 v2) - там много чего крутится: SQL, антивирус, 10-15 пользователей и базы Access.
И есть сервер тестовый. Вот там голая винда, без антивируса и всего прочего. Только Windows Server 2008 и Access 2010. И ни одного пользователя, кроме меня.

AkinavmagПопробуйте сделать простой эксперимент - выдерните после работы сервак из LAN,
перезагрузите, подождите минут 5 и потом подергайте локально базу - каков будет результат ?Некорректно - все сетевые службы всё равно будут в состоянии готовности. Корректнее (но всё равно некорректно) будет "погасить" сетевые интерфейсы.

Safichна серверных машинах база тормозит.Это правильно - на сервере пользовательские сеансы обрабатываются "по остаточному принципу". На нём элементарно бОльшая часть оперативки используется под файловые кэши - кроме, конечно, серверов, на которых в принципе отсутствует не то что роль файлопомойки, но и сама возможность получения этой роли (впрочем, серверы без службы доступа к файлам и принтерам такая редкость - но на таких обычно взамен стоИт какой-нить прожорливый SQL-сервер...).
SafichОдин из разработчиков утверждает, что в процессе поиска у него подключается второе ядроДумаю, если он принудительно отключит такую возможность ручной установкой аффинити для Аксесса, скорость обработки только возрастёт.
1) Предположим, но тогда почему на машине под номером 2 тоже на сервере, но с несерверным процессором таких проблем нет?
2) База "кушает" примерно 50 МБ оперативки
3) А вот про аффинити подробнее, если можно

AkinaSafich1) Предположим, но тогда почему на машине под номером 2 тоже на сервере, но с несерверным процессором таких проблем нет?Я не понимаю, с чего ты решил, что проблема в типе процессора? тем более что деление процессоров на "серверные" и "десктопные" в большей степени условно, чем имеет под собой реальные к такому делению основания.
Проблема - в оптимизации операционной системы под тип задач.

Safich2) База "кушает" примерно 50 МБ оперативки
Как определил? это даже не заостряя внимания на то, что база вообще ничего не "кушает", она суть просто файл с данными.

Safich3) А вот про аффинити подробнее, если можно
Affinity mask - битовая маска, определяющая, какие процессоры в многопроцессорной системе может использовать поток исполнения.

1) Как определил? Методом исключения. Есть машина с Windows Server - там тормозов нет.
2) Я про базу, которая клиент :)
3) Affinity mask это ж вроде SQL Server, а у меня файл-сервер. Беглый поиск не дал результатов Affinity mask + MS Access

Внимание! У меня НЕ SQL. У меня тут Access (БД) + Access (Клиент). Какой-такой поиск НЕ в клиенте?

DAO, ADO... какая разница вот конкретно в этом случае?
Моя логика в отношении DAO/ADO проста: если база данных Access, то DAO, если SQL - ADO.
Сути это не меняет, хоть я перебором в текстовом файле искать буду.

Почему. Одна. И. Та. Же. Программа. Ведёт. Себя. По. Разному. На. Разных. Машинах?