SELECT ID_
FROM (SELECT ID_, Y1, Z1, Y2, Z2, Y3, Z3
FROM rezsort WHERE ID_ < @curr AND Zone = @Zone) AS rezsort_prior
WHERE
((Y1 > @y_min AND Y1 < @y_max) AND (Z1 > @z_min AND Z1 < @z_max))
OR ((Y2 > @y_min AND Y2 < @y_max) AND (Z2 > @z_min AND Z2 < @z_max))
OR ((Y3 > @y_min AND Y3 < @y_max) AND (Z3 > @z_min AND Z3 < @z_max))
Загрузить процессор на 100%
Есть приложение, работающее с БД M$ SQL Server 2000/2005, связка ADO.
Работа приложения заключается в том что в главном потоке приложения организован цикл с обращением на выборку из БД, каждая последующая итеррация берет данные из предыдущей, поэтому многопоточно сделать довольно проблематично.
Когда запускал на компе с целероном - загрузка была 100% (на приложение 20-40% на сервер 60-80%).
Запустил все это на 2-х ядерном процессоре, думал быстрее будет, однако общая загрузка 50%, из них 0-15% на приложение и 35-50% на сервер.
Хотелось бы использовать всю мощь процессора (обоих ядер) на 100%. Что в приложенни и в настройках сервера надо подкурутить?
Работа приложения заключается в том что в главном потоке приложения организован цикл с обращением на выборку из БД, каждая последующая итеррация берет данные из предыдущей, поэтому многопоточно сделать довольно проблематично.
Когда запускал на компе с целероном - загрузка была 100% (на приложение 20-40% на сервер 60-80%).
Запустил все это на 2-х ядерном процессоре, думал быстрее будет, однако общая загрузка 50%, из них 0-15% на приложение и 35-50% на сервер.
Хотелось бы использовать всю мощь процессора (обоих ядер) на 100%. Что в приложенни и в настройках сервера надо подкурутить?
Возможно стоит сделать индексы в БД, это может ускорить выборку.
Ну и видимо стоит переписать алгоритм обработки выборки на клиенте с учетом многопоточности. Также стоит сделать кэширование частых запросов на клинете - возможно он засыпает сервер мелкими запросами.
Ну и видимо стоит переписать алгоритм обработки выборки на клиенте с учетом многопоточности. Также стоит сделать кэширование частых запросов на клинете - возможно он засыпает сервер мелкими запросами.
чет по мойму 2000-ый сервер не оптимизирован под многоядерность. про 2005 не знаю. ну и софтина не многопоточная (в контексте данной задачи) -> имхо особо не изощришься.
Цитата: hardcase
Возможно стоит сделать индексы в БД, это может ускорить выборку.
Ну и видимо стоит переписать алгоритм обработки выборки на клиенте с учетом многопоточности. Также стоит сделать кэширование частых запросов на клинете - возможно он засыпает сервер мелкими запросами.
Ну и видимо стоит переписать алгоритм обработки выборки на клиенте с учетом многопоточности. Также стоит сделать кэширование частых запросов на клинете - возможно он засыпает сервер мелкими запросами.
Индексы везде где надо есть.
Запрос всегда только один выполняется, я его вообще в ХП перенес, и передаю только значения аргументов. Обработка выборки на клиенте простейшая - на определенном шаге итерации из выполненного запроса получить значения и подставить их в следующую итерацию.
Цитата: Washington
чет по мойму 2000-ый сервер не оптимизирован под многоядерность. про 2005 не знаю. ну и софтина не многопоточная (в контексте данной задачи) -> имхо особо не изощришься.
Запускал на 2005 exspress, а с 2000 просто совместимо вся эта байда.
Мне просто интересно, почему сервер не юзает весь процессор? зачем он оставляет кому то ресурсы, и как его заставить все эти ресурсы под себя забрать.
А ты уверен, что эти ресурсы ему точно нужны? Ведь работа с БД это не только вычисление - это еще и чтение данных.
Цитата: oxotnik333
Мне просто интересно, почему сервер не юзает весь процессор? зачем он оставляет кому то ресурсы, и как его заставить все эти ресурсы под себя забрать.
Так уж он работает. Кстати, processor-affinity может быть настроена криво у него?
Цитата: aks
А ты уверен, что эти ресурсы ему точно нужны? Ведь работа с БД это не только вычисление - это еще и чтение данных.
Данных там не особо много, около 500 мб база, а сама таблица из которой делаются выборки наверно половину базы занимает, т.е. в 1Гб оперативки вполне все умещается и диск не трогает почти.
Цитата: oxotnik333
Данных там не особо много, около 500 мб база, а сама таблица из которой делаются выборки наверно половину базы занимает, т.е. в 1Гб оперативки вполне все умещается и диск не трогает почти.
Значит планировщик в сиквеле тупо не может распараллелить запрос. Может имеет смысл запрос оптимизировать?
Цитата: oxotnik333
Мне просто интересно, почему сервер не юзает весь процессор? зачем он оставляет кому то ресурсы, и как его заставить все эти ресурсы под себя забрать.
Насколько я понял вопрос, ответ должен звучать примерно так:
однопоточное приложение принципиально не может загрузить больше одного ядра, т.е. 50% у двухъядерного процессора, 25% у четырехъядерного и т.д.
Т.о. если хочешь взять максимум от многоядерного процессора, ничего другого не остается, как писать многопоточное приложение.
Цитата: andriano
Насколько я понял вопрос, ответ должен звучать примерно так:
однопоточное приложение принципиально не может загрузить больше одного ядра, т.е. 50% у двухъядерного процессора, 25% у четырехъядерного и т.д.
Т.о. если хочешь взять максимум от многоядерного процессора, ничего другого не остается, как писать многопоточное приложение.
однопоточное приложение принципиально не может загрузить больше одного ядра, т.е. 50% у двухъядерного процессора, 25% у четырехъядерного и т.д.
Т.о. если хочешь взять максимум от многоядерного процессора, ничего другого не остается, как писать многопоточное приложение.
Да причем тут приложение. Надо что бы сервер нагружал процессор, т.к. это самое нагруженное звено в связке сервер-клиент.
Получается, что приложение (а вернее связка) мультипоточная. Я тоже склоняюсь к некорректной расстановке процессов по ядрам, возможно они оба висят на одном ядре. Ну а если не так, то дело, очевидно, не в мощности процессора.
где то я видел прожку, с помощью которой можно раскидывать процессы на разные ядра и пр. может там чего есть. как называется не помню, и не уверен, че она умеет, потому что я себе не представляю, как это можно реализовать. но имеет смысл погуглять.
Цитата: oxotnik333
Запускал на 2005 exspress, а с 2000 просто совместимо вся эта байда.
Мне просто интересно, почему сервер не юзает весь процессор? зачем он оставляет кому то ресурсы, и как его заставить все эти ресурсы под себя забрать.
Мне просто интересно, почему сервер не юзает весь процессор? зачем он оставляет кому то ресурсы, и как его заставить все эти ресурсы под себя забрать.
Внимательно читаем ограничения экспресс-версий.
Цитата: Der Meister
Внимательно читаем ограничения экспресс-версий.
[quote=Internet]
- [FONT=Georgia][SIZE=2]Maximum database size: 4 GB[/SIZE][/FONT]
- [FONT=Georgia][SIZE=2]Maximum memory used: 1 GB[/SIZE][/FONT]
- [FONT=Georgia][SIZE=2]Maximum CPUs used: 1[/SIZE][/FONT]
Так это вроде к процессорам относится а не к ядрам процессорным. В Windows XP вот ограничение на два процессора, но на моем четырехядернике вполне стартует.
Цитата: Der Meister
Внимательно читаем ограничения экспресс-версий.
И не кастрированный MS SQL 2005 запускал, такая же беда.
Цитата: Angerslave
Получается, что приложение (а вернее связка) мультипоточная. Я тоже склоняюсь к некорректной расстановке процессов по ядрам, возможно они оба висят на одном ядре. Ну а если не так, то дело, очевидно, не в мощности процессора.
Оба ядра задействованы на 50%.
Цитата: oxotnik333
Есть приложение, работающее с БД M$ SQL Server 2000/2005, связка ADO.
Работа приложения заключается в том что в главном потоке приложения организован цикл с обращением на выборку из БД, каждая последующая итеррация берет данные из предыдущей, поэтому многопоточно сделать довольно проблематично.
Когда запускал на компе с целероном - загрузка была 100% (на приложение 20-40% на сервер 60-80%).
Запустил все это на 2-х ядерном процессоре, думал быстрее будет, однако общая загрузка 50%, из них 0-15% на приложение и 35-50% на сервер.
Хотелось бы использовать всю мощь процессора (обоих ядер) на 100%. Что в приложенни и в настройках сервера надо подкурутить?
Работа приложения заключается в том что в главном потоке приложения организован цикл с обращением на выборку из БД, каждая последующая итеррация берет данные из предыдущей, поэтому многопоточно сделать довольно проблематично.
Когда запускал на компе с целероном - загрузка была 100% (на приложение 20-40% на сервер 60-80%).
Запустил все это на 2-х ядерном процессоре, думал быстрее будет, однако общая загрузка 50%, из них 0-15% на приложение и 35-50% на сервер.
Хотелось бы использовать всю мощь процессора (обоих ядер) на 100%. Что в приложенни и в настройках сервера надо подкурутить?
Этот вопрос обсуждался однажды на форуме - насколько я помню по итогам того обсуждения был сделан вывод о невозможности. Почему и как ищите тему и читайте.
хм... поиск по МСДН-у выдал:
Параметр priority boost предназначен для указания того, должен ли Microsoft SQL Server выполняться с большим приоритетом планирования в Microsoft Windows 2000 или Windows Server 2003, чем остальные процессы на том же компьютере. Если установить этот параметр в значение 1, SQL Server выполняется в планировщике Windows 2000 или Windows Server 2003 с базовым приоритетом 13. Значением по умолчанию является 0, что соответствует базовому значению приоритета 7.
ЗЫ: про XP ни слова...
Цитата:
Параметр priority boost предназначен для указания того, должен ли Microsoft SQL Server выполняться с большим приоритетом планирования в Microsoft Windows 2000 или Windows Server 2003, чем остальные процессы на том же компьютере. Если установить этот параметр в значение 1, SQL Server выполняется в планировщике Windows 2000 или Windows Server 2003 с базовым приоритетом 13. Значением по умолчанию является 0, что соответствует базовому значению приоритета 7.
скрипт, что бы поменять приоритет:
Код:
sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
sp_configure 'priority boost', 1; -- здесь задается значение приоритета
GO
RECONFIGURE;
GO
GO
RECONFIGURE;
GO
sp_configure 'priority boost', 1; -- здесь задается значение приоритета
GO
RECONFIGURE;
GO
ЗЫ: про XP ни слова...
выдать то поиск выдал, помогло хоть? )
Цитата: Washington
выдать то поиск выдал, помогло хоть? )
доберусь до 2-х ядерного - проверю... а то на работе помойка стоит, нет возможности протестить :)
Цитата: oxotnik333
хм... поиск по МСДН-у выдал
Да я прям так скажу - не поможет :)
Это всеглишь приоритеты в вытесняющей многозадачности. Проблему с однопоточным исполнением запроса это не решит.
Цитата: hardcase
Да я прям так скажу - не поможет :)
Это всеглишь приоритеты в вытесняющей многозадачности. Проблему с однопоточным исполнением запроса это не решит.
Это всеглишь приоритеты в вытесняющей многозадачности. Проблему с однопоточным исполнением запроса это не решит.
не помогло... :(
причем на одноядерной машине время выполнения процентов на 10 меньше чем на 2-х ядерной....
Цитата: oxotnik333
причем на одноядерной машине время выполнения процентов на 10 меньше чем на 2-х ядерной....
Это планировщик балансирует загрузку процессорных ядер.
А задачу точно нельзя распараллелить "вертикально"? Т.е. разбиваем таблицу на две и выполняем аналогичный алгоритм на каждой половине. Результат объединяем.
Цитата: hardcase
Это планировщик балансирует загрузку процессорных ядер.
А задачу точно нельзя распараллелить "вертикально"? Т.е. разбиваем таблицу на две и выполняем аналогичный алгоритм на каждой половине. Результат объединяем.
А задачу точно нельзя распараллелить "вертикально"? Т.е. разбиваем таблицу на две и выполняем аналогичный алгоритм на каждой половине. Результат объединяем.
Тут смысл немного в другом. Когда разрабатывал прогру (тестил на одном проце), мне че то в голову не пришло что сервер так будет себя вести, думал чем больше ядер/процов на машине тем шустрее сервер будет отдавать результаты, т.е. если взять 32-х ядерный сервак, то и соответсвенно скорость раз в 30 увеличится (глупые мечты конечно).
А смысл самой задачи - уменьшить скорость расчета в десятки раз, посему если даже на 2 задачи разбить, то скорость всего в 2 раза возрастет на любой машине, а это не есть конечная точка.
Придется организовывать очередь процессов и стек с расчетами.
а сколько потоков делать?
Цитата: oxotnik333
Что в приложенни и в настройках сервера надо подкурутить?
Я, пожалуй, тоже вякну, несмотря на то, что работаю с Oracle, а не с MS SQL. Думаю, что многое из технологий, предлагаемых Oracle, есть и в MS SQL.
1. Редко изменяемые справочники лучше хранить не кучей, а в виде Index-Organized Tables (IOT).
2. Если существуют таблицы, в которые периодически добавляются данные, но редко изменяются, их можно партиционировать по какому-либо признаку (по какому конкретно -- зависит от характера выборок и добавок). Точнее, важно, чтобы не изменялись значения тех столбцов, по которым партиционировали таблицу.
3. В некоторых случаях (например, если данные из нескольких таблиц выбираются в подавляющем большинстве вместе, типа SELECT ... FROM table1 INNER JOIN table2 ON table1.xxx = table2.yyy), таблицы можно кластеризовать по индексу или по хэшу. Классический пример из Тома Кайта таблиц в индексном кластере -- таблицы отделов и сотрудников. [quote=Tom Kyte]Однако, если предполагается активное изменение таблиц в кластере, необходимо учитывать, что индексный кластер будет снижать производительность. Для управления данными в кластере необходимо выполнить больше действий.[/quote]
4. Если есть какая-нибудь сложная выборка из таблицы, которая очень редко обновляется, можно создать материализованное представление.
5. В некоторых случаях эффективнее строить не B-индексы, а Bitmap-индексы (но с ними много подводных камней).
Используя эти фенечки, можно ускорить выборки в разы по сравнению с традиционными "плоскими" таблицами и индексами B-Tree.
Да, чуть не забыл: Оксотник, я тебя прощаю! ;)