Актуальность рекомендаций о разделении пространств по разным дискам. / Informix

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Informix [игнор отключен] [закрыт для гостей] / Актуальность рекомендаций о разделении пространств по разным дискам.

25 сообщений из 63, страница 2 из 3

все

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168506

Rent_y

Гость

to Павел. С - Обновление статистики high-level - хорошо нагружает темпы.

...

Рейтинг:

0 / 0

28.08.2009, 17:03

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168526

Павел. С

Гость

aist-pskПавел. С,

/usr/informix/data/ram0_data.gz
а это образ чего ?

Это образ чанка, который проинициализировал IDS при добавлении чанка (onspaces). Это обычный файл, который сразу после создания (это важно) прогнали через gzip.

Размер у файла получился 2'035'478 байта. Распаковывается в RAM диск в 2'097'152'000 байт перед каждым стартом информикса.

Надеюсь, понятно написал. Если не понятно - могу подробней.

...

Рейтинг:

0 / 0

28.08.2009, 17:14

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168632

АнатоЛой

Участник

Откуда: Киев, Украина

Сообщения: 2 910

Рейтинг: 0 / 0

Павел. СДумаю, на синтетических тестах должна быть видна разница.
по тому же onstat -D и нужно было следить - есть нагрузка на темпЫ, или нету...

...

Рейтинг:

0 / 0

28.08.2009, 18:10

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168636

Павел. С

Гость

Rent_yto Павел. С - Обновление статистики high-level - хорошо нагружает темпы.

Cделал только что UPDATE STATISTICS HIGH FOR TABLE table1(row1)

в таблице около 100 млн записей. Процесс занимает около 80 секунд.

IO в tempdbs практически нет...

Вроде подобрал запрос, с сортировками и группировками, который сильно грузит tempdbs. Позже отпишу о результатах.

...

Рейтинг:

0 / 0

28.08.2009, 18:12

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168642

Павел. С

Гость

АнатоЛой,

АнатоЛойпо тому же onstat -D и нужно было следить - есть нагрузка на темпЫ, или нету...

Вот по нему и определяю.

...

Рейтинг:

0 / 0

28.08.2009, 18:16

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168677

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

Павел. СЯ по своему опыту скажу, также насмотрелся на большую IO нагрузку на временные пространства, и решил таки попробовать их вынести в РАМ.

Никакого прироста в скорости не получил ))) Хотя, возможно, бенчмарки делал криво.Да. Я такое тоже наблюдал. Просто длительность i/o операций не есть узкое место, они тоже кешируются в буферах. Алгоритм сортировки разный для one-pass, multi-pass режимов, а когда выбран multi-pass уже не важно где темп на диске или в памяти, а увеличение non_pdq со 128 до 256 увеличивает вероятность one-pass до скажем 90%, а 512 до 99%. А бывает что темп и вообще i/o это не узкое место, а узкое место просто огромное количество операций чтения из памяти (логические чтения в терминах оракла).

...

Рейтинг:

0 / 0

28.08.2009, 18:45

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168696

Павел. С

Гость

Надеюсь, топикстартеру это как-то поможет, не хочется писать совсем оффтоп.

Проверил скорость выполнения запроса, активно использующего tempdbs, в 2х вариантах:
1) tempdbs - Это raw устройство.
2) tempdbs - это файл на RAM диске.

В системе корзина на 24 диска под данные IDS. Из всех дисков собран RAID10, который побит на логические диски. У контроллера 256 МБ кеша. 75% на запись.
ОС - RedHat 5
IDS - 11.50 FC5
RAM 8ГБ
4 ядра ЦПУ Intel Core2.

Запрос

Код: plaintext

1.
2.
3.

select count(*), field1
from table1
group by field1
order by count(*) desc

В таблице 2 млн записей. Поле field1 уникально. Индекса по field1 нет. Длина field1 около 100 байт.

Перед тестированием выполнял перезагрузку сервера, пару раз выполнял запрос и занулял все счетчики (onstat -z). Чтения данных с обычных DBspace не было, все читалось из Buffers Pool'а.

Результаты по количеству операций IO ( onstat -D | grep -v '0 0' ), что ожидаемо, получил абсолютно одинаковые для обоих вариантов:

Код: plaintext

1.
2.
3.

Chunks
address          chunk/dbs     offset     page Rd  page Wr  pathname
15664b028        2      2      0          816705   876316   /usr/informix/data/tempdbs1ram

onstat -g iof уже интересней:

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.

RAW 
onstat -g iof
gfd pathname         bytes read     page reads  bytes write    page writes io/s
4   tempdbs1ram      1672665088     816731      1794703360     876320      7287.1
	op type     count          avg. time
	seeks       0              N/A
	reads       0              N/A
	writes      0              N/A
	kaio_reads  189041         0.0002
	kaio_writes 190877         0.0001
------------------------------------------
RAM
onstat -g iof
gfd pathname         bytes read     page reads  bytes write    page writes io/s
4   tempdbs1ram      1672615936     816707      1794703360     876320      88106.1
	op type     count          avg. time
	seeks       0              N/A
	reads       189017         0.0000
	writes      190343         0.0000
	kaio_reads  0              N/A
	kaio_writes 0              N/A

И результаты по времени работы
1) tempdbs на RAW device 52 сек
2) tempdbs в файле на RAM диске 21 сек

конфиг кому интересно - приложил.

Но на реальной работе приложения в моем случае это никак не отражается((

Журавлев Денис выше написал, почему

...

Рейтинг:

0 / 0

28.08.2009, 19:07

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168717

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

vasilisТы , возможно, не представляешь себе их систему. Она и большая, и лоскутная Так у всех такие системы. Главное нАчать.

Я недавно в zabbix-е один запрос имеющий where mod(f0)=:f поправил (функциональных индексов в mysql нет), загрузка процессора с 50% до 2% упала.

...

Рейтинг:

0 / 0

28.08.2009, 19:29

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168760

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Павел. С
И результаты по времени работы
1) tempdbs на RAW device 52 сек
2) tempdbs в файле на RAM диске 21 сек
Доказательство налицо. И уже это меня радует своей логичностью.
Спасибо вам за "не ленивость" и любознательность.
Павел. СНо на реальной работе приложения в моем случае это никак не отражается((
Вряд ли "никак".
Вы же сами признали. что никаких бенчмарков не делали, все было "на глазок" по стандартной работе. И, наверное, ожидали, как и многие, прибавления в скорости в 2 раза на всех видах запросов ?
Так не бывает.
Как минимум, всегда нужно иметь инструментарий для измерений (как в вашем синтетическом случае) и правильно проводить измерения. Во вторых, "волшебной пули" не бывает и результат даже в 5% можно считать хорошим, а в 10% - отличным (а этот результат "на глазок" уловить трудно). И если таких улучшений по 5% набрать несколько, то уже можно будет говорить о существенном улучшении производительности системы. То же самое, значительно меньшей кровью, достигается просто за счет железа и по этому пути , обычно, и следуют.
Я уж не говорю о случаях бездарно написаных запросов, глупой структуры БД, отсутствия индексов, "странного" конфигурирования сервера, просто необновления статистики и т.п.

Павел. Сконфиг кому интересно - приложил.
да уж, конфиг "интересный". Надеюсь, что экспериментировали не на продакшене ? :)
Кто же это вам посоветовал такие параметры пробовать ?

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

#RA_PAGES     200002
#RA_THRESHOLD 199998
#RA_PAGES     800002  # Index build = 3 h
#RA_THRESHOLD 799998
RA_PAGES	512 # load 5h, index build 4h
RA_THRESHOLD	508

#RA_PAGES	2048 # load , index build 3 h
#RA_THRESHOLD	2044

#RA_PAGES	500002 # load, index build 2.30 with RAM tempdbs, 2.17 with no partial, 3.3h
#RA_THRESHOLD	499998

...

Рейтинг:

0 / 0

28.08.2009, 20:46

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168762

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Rent_yto Павел. С - Обновление статистики high-level - хорошо нагружает темпы.
У вас очень разные версии, соответственно и поведение серверов очень отличается при update stat...

...

Рейтинг:

0 / 0

28.08.2009, 20:49

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168768

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Rent_yto vasilis: Задача крайне не тривиальная - очень большая база для базового уровня - более 10Гб, 200 одновременных подключений. Стандартные рекомендации по большей части не приемлемы, стандратное железо, которое у нас используется тоже. Уже несколько недель находимся в постоянном поиске и настройки разные пробуем и разработчики помогают, но не хватает знаний и практики в настройке такой системы.
Да, 10Г для вашей системы многовато и, похоже, что опыта в решении проблем производительности для такой конкретной системы нет не только у вас.
Когда то уже пытались решать похожую задачу на верхнем уровне (общая БД в СЗ) и поняли - это система и проектировалась и разрабатывалась и настраивалась для работы на базовом уровне (до 50 пользователей и сотни метров оперативных данных). Системы с более тяжелой нагрузкой и объемами требуют других подходов. Изменить их, насколько я понимаю, проблематично и сейчас.
Кстати, вроде была на подходе новая система с другой архитектурой (Web-клиент) и другой СУБД ?
Или пока не сложилось ?

Rent_yПробовали и два темповых пространства внутри 10 рейда создавать - особой разницы в производительности не наблюдали и второй темп отключили. Теперь решили попробовать по разным дискам темпы разнести, как раз возможность модернизации дисковой подсистемы появилась...
А как вы эту разницу определяли ? Снова на глазок, ожидая ускорения в два раза ?
Я как то уже описывал в конфе (и несколько раз), что эксперименты именно на этой версии 9.3 показывали улучшение производительности от распараллеливания темпов даже если они находились на одном диске (устройстве). И если это хоть иногда помогает, пусть на небольшой части запросов, то почему бы этим не воспользоваться ?

...

Рейтинг:

0 / 0

28.08.2009, 21:03

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168785

Павел. С

Гость

vasilis
да уж, конфиг "интересный". Надеюсь, что экспериментировали не на продакшене ? :)

Да, конфиг эксперементальный. Хотя это железо и эти версии ОС и IDS планируется вводить в продакшн.

vasilis
Кто же это вам посоветовал такие параметры пробовать ?
Никто не советовал))
А что в этих параметрах "не так"? Абсолютные значения или отношение RA_PAGES к RA_THRESHOLD?
Я пытался ускорить построение индексов.

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

...

Рейтинг:

0 / 0

28.08.2009, 21:16

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168788

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Журавлев ДенисvasilisТы , возможно, не представляешь себе их систему. Она и большая, и лоскутная Так у всех такие системы. Главное нАчать.
Угу.
Но нет у них сейчас Дениса Журавлева ;)

P.S. А так, пытались и не раз. И даже результаты сильно улучшали. И выносить в архивные данные из оперативных научились и выкидывать что-то лишнее, и запросы и процедуры переписывать и т.п.
Если сильно придавят, то снова будут что-то делать.

...

Рейтинг:

0 / 0

28.08.2009, 21:18

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168796

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Павел. Сvasilis
Кто же это вам посоветовал такие параметры пробовать ?
Никто не советовал))
А что в этих параметрах "не так"? Абсолютные значения или отношение RA_PAGES к RA_THRESHOLD?
И то и другое.
Похоже, что вы не совсем понимаете их смысл.
Некоторые здесь до сих пор боятся эти параметры устанавливать :)
некоторые считали, что больше big buffer-а (32) все равно не имеет смысла.
Но версии меняются и смысл значений параметров тоже меняется - надо читать доки и внимательно и вдумчиво пробовать на конкретной системе.
P.S. Поищите по форуму - мне помнится на эту тему не раз говорили.
Павел. СХотя по железу новая система получше. Хочу по этому поводу создать новый тред в форуме, надеюсь уважаемые форумчане мне помогут разобраться с ошибками в настройке.
Да, лучше отдельный топик и с подробностями, своими экпериментами и выводами - тогда народ, возможно, будет критиковать, предлагать и фантазировать :)

...

Рейтинг:

0 / 0

28.08.2009, 21:30

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36168810

Яковлев Павел

Гость

Rent_yЗадача крайне не тривиальная - очень большая база для базового уровня - более 10Гб
Попробую заняться ясновидением - мать куда вы можете вставить "8 портовый рейд-контроллер SRCSASBB8I" cкорее всего запросто может иметь 32G RAM

Вот их и поставьте - система 1-2G + пуферпул и прочее информикса 10-16G + остальное можно во временное(ые) пространство(ва)

А диски - ТОЛЬКО SAS - проверено на двух во всём одинаковых машинах у одной из которых "серверные" SATA , а у другой "просто" SAS 15Krpm

Rent_yначались жалобы на очень медленную работу
А СPU точно хватает ?

...

Рейтинг:

0 / 0

28.08.2009, 21:52

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36169050

Rent_y

Гость

to vasilis: Новая платформа пока ещё в отдаленной перспективе - финансовый кризис не миновал и СЗУ(((. Производительность проверял поочередно запуская обновление статистики и несколько емких статотчетов(каждая операция выполняется больше часа). Пробовал c двумя вариантами buffers: 350000 и 10000 - при одинаковых значениях buffers результат получался практически одинаковый что при одном что при двух темпах. Заметил что работа с темповыми простанствами идет не параллельно, то есть сначала идет работа с 1-ым темпом потом со вторым, после того как второй примерно выровнялся с первым - опять работа с первым. Мониторил операции ввода/вывода по onstat -g iof и заполнение по onstat -d.

...

Рейтинг:

0 / 0

29.08.2009, 12:58

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36169054

Rent_y

Гость

to Павел. С: Реализация интересная, к сожалению плохо представляю как смонитровать виртуальный диск в оперативной памяти под Windows, попробую поработать в этом направлении.

to Яковлев Павел: Под Informix 9.3 больше ~ 2,2ГБ ОЗУ отдать у меня не получается, С процессорами проблем нет - они вполне справляются.

...

Рейтинг:

0 / 0

29.08.2009, 13:09

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36169055

aist-psk

Участник

Откуда: где-то возле балтики

Сообщения: 764

Рейтинг: 0 / 0

Павел. С,

понятно , спасибо.
вопрос: когда информикс останавливается(или restart) текущее состоянии чанка tempdb обратно в файл сливаете ?

...

Рейтинг:

0 / 0

29.08.2009, 13:22

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36169090

Павел. С

Гость

aist-pskвопрос: когда информикс останавливается(или restart) текущее состоянии чанка tempdb обратно в файл сливаете ?

Нет, ничего на диск не скидываю. Только с диска. Т.е. IDS при старте всегда видит "чистый" tempdbs.

На то он и temp ))

...

Рейтинг:

0 / 0

29.08.2009, 14:27

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36169121

aist-psk

Участник

Откуда: где-то возле балтики

Сообщения: 764

Рейтинг: 0 / 0

Павел. С,

Благодарю.

...

Рейтинг:

0 / 0

29.08.2009, 15:23

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36170021

Daugava

Участник

Откуда: Riga-Kiev-Gurzuf

Сообщения: 718

Рейтинг: 0 / 0

Я размазывал все на разные диски 7 лет назад с разнесением архивов, фрагментацией дневных таблиц. Тогда имелось 14 дисков на RAID-е и еще 4 на обычном SCSI контролере, отведенные под tempdbs-ы. Это позволило прожить 6 лет практически без изменения конфигурации (разве что через 3 года четыре 18 Гб винтов архивных данных были заменены на 72Гб) . Год назад система переехала на новое железо, SAN, Fibre Channel. Запас у железа по производительности был настолько велик, а планы на развитие в связи с кризисом настолько серьезно изменены, что сейчас данные по дискам не разносятся никак. Просто на SAN-е выделен RAID10 из 4x140Гб винтов. Более того, они живут не в "сырых" устройствах и прекрасно себя чувствуют. Единственное, что сделал - это отдельные dbspace для логов, данных и темпов.

P.S. Тут упоминались тесты производительности с помощью update statistics и т.д. Обращу внимание, что тест должен проивзодиться прежде всего ради юзеров. Изменения при наличии одного активного пользователя в системе, действительно может не дать эффекта, а когда на базе сидят юзера и дерутся за ресурсы, эффект может оказаться совсем другим.

...

Рейтинг:

0 / 0

31.08.2009, 10:34

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36170281

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Rent_yЗаметил что работа с темповыми простанствами идет не параллельно, то есть сначала идет работа с 1-ым темпом потом со вторым, после того как второй примерно выровнялся с первым - опять работа с первым. Мониторил операции ввода/вывода по onstat -g iof и заполнение по onstat -d.
А уже ранее просил, повторюсь еще раз:
"Покажите onstat -d и DBSPACETEMP из onconfig (и не забудьте о такой же переменной окружения)"
а лучше onconfig целиком.

...

Рейтинг:

0 / 0

31.08.2009, 12:03

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36170300

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

Rent_yС процессорами проблем нет - они вполне справляются.
Действительно ?
Т.е. средняя нагрузка на процы в рабочее время у вас значительно меньше 50%, а в пиковые нагрузки 100% загрузка по длительности не превышает 10сек ?

...

Рейтинг:

0 / 0

31.08.2009, 12:07

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36170318

Rent_y

Гость

Informix Dynamic Server Version 9.30.TC2 -- On-Line -- Up 1 days 13:35:37 -- 2020992 Kbytes

Dbspaces
address number flags fchunk nchunks flags owner name
44f867d0 1 0x1 1 1 N informix rootdbs
45418ed0 2 0x11 2 2 N B informix blobdbs
4541c180 3 0x8001 3 1 N S informix sbspace
4541c2c8 4 0x1001 5 2 N informix tempdbs_log
4541c410 5 0x1 6 2 N informix logdbs
4541c558 6 0x1 8 1 N informix phisdbs
4541c6a0 7 0x1 9 26 N informix workdbs
4541c7e8 8 0x2001 14 10 N T informix tempdbs
8 active, 2047 maximum

Note: For BLOB chunks, the number of free pages shown is out of date.
Run 'onstat -d update' for current stats.

Chunks
address chk/dbs offset size free bpages flags pathname
44f86918 1 1 0 102400 100904 PO- D:\IFMXDATA\ol_employment\rootdbs_dat.000
454180c0 2 2 0 524032 ~524032 524032 POB d:\ifmxdata\ol_employment\blobdbs_dat.000
45418228 3 3 0 12800 11886 11886 POS D:\IFMXDATA\ol_employment\sbspace_dat.000
Metadata 861 556 861
45418390 4 2 0 524032 ~524032 524032 POB d:\ifmxdata\ol_employment\blobdbs_dat.001
454184f8 5 4 0 524032 517038 PO- d:\ifmxdata\ol_employment\tempdbs_log_dat.000
45418660 6 5 0 524032 3979 PO- d:\ifmxdata\ol_employment\logdbs_dat.000
454187c8 7 5 0 524032 44029 PO- d:\ifmxdata\ol_employment\logdbs_dat.001
45418930 8 6 0 131072 197 PO- d:\ifmxdata\ol_employment\phisdbs_dat.000
45418a98 9 7 0 524032 2 PO- d:\ifmxdata\ol_employment\workdbs_dat.000
45418c00 10 7 0 524032 1 PO- d:\ifmxdata\ol_employment\workdbs_dat.001
45418d68 11 7 0 524032 1 PO- d:\ifmxdata\ol_employment\workdbs_dat.002
45419018 12 7 0 524032 1 PO- d:\ifmxdata\ol_employment\workdbs_dat.003
45419180 13 7 0 524032 1 PO- d:\ifmxdata\ol_employment\workdbs_dat.004
454192e8 14 8 0 524032 412480 PO- d:\ifmxdata\ol_employment\tempdbs_dat.000
45419450 15 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.001
454195b8 16 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.002
45419720 17 7 0 524032 2 PO- d:\ifmxdata\ol_employment\workdbs_dat.005
45419888 18 7 0 524032 2 PO- d:\ifmxdata\ol_employment\workdbs_dat.006
454199f0 19 7 0 524032 1 PO- d:\ifmxdata\ol_employment\workdbs_dat.007
45419b58 20 7 0 524032 3 PO- d:\ifmxdata\ol_employment\workdbs_dat.008
45419cc0 21 7 0 524032 1 PO- d:\ifmxdata\ol_employment\workdbs_dat.009
45419e28 22 7 0 524032 3 PO- d:\ifmxdata\ol_employment\workdbs_dat.010
4541a018 23 7 0 524032 3 PO- d:\ifmxdata\ol_employment\workdbs_dat.011
4541a180 24 7 0 524032 1 PO- d:\ifmxdata\ol_employment\workdbs_dat.012
4541a2e8 25 7 0 524032 105 PO- d:\ifmxdata\ol_employment\workdbs_dat.013
4541a450 26 7 0 524032 448773 PO- d:\ifmxdata\ol_employment\workdbs_dat.014
4541a5b8 27 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.015
4541a720 28 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.016
4541a888 29 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.017
4541a9f0 30 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.018
4541ab58 31 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.019
4541acc0 32 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.020
4541ae28 33 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.021
4541b018 34 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.022
4541b180 35 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.023
4541b2e8 36 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.024
4541b450 37 7 0 524032 524029 PO- d:\ifmxdata\ol_employment\workdbs_dat.025
4541b5b8 38 8 0 524032 523629 PO- d:\ifmxdata\ol_employment\tempdbs_dat.003
4541b720 39 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.004
4541b888 40 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.005
4541b9f0 41 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.006
4541bb58 42 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.007
4541bcc0 43 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.008
4541be28 44 8 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_dat.009
4541c018 45 4 0 524032 524029 PO- d:\ifmxdata\ol_employment\tempdbs_log_dat.001
45 active, 2047 maximum

...

Рейтинг:

0 / 0

31.08.2009, 12:11

| Ответить | Цитировать | Написать

Актуальность рекомендаций о разделении пространств по разным дискам.

#36170336

zaiets

Гость

Rent_yto vasilis: Новая платформа пока ещё в отдаленной перспективе - финансовый кризис не миновал и СЗУ(((. Производительность проверял поочередно запуская обновление статистики и несколько емких статотчетов(каждая операция выполняется больше часа). Пробовал c двумя вариантами buffers: 350000 и 10000 - при одинаковых значениях buffers результат получался практически одинаковый что при одном что при двух темпах. Заметил что работа с темповыми простанствами идет не параллельно, то есть сначала идет работа с 1-ым темпом потом со вторым, после того как второй примерно выровнялся с первым - опять работа с первым. Мониторил операции ввода/вывода по onstat -g iof и заполнение по onstat -d.

Судя по диалогу, система у вас от Срфтлайн на их сервере приложений.
Если єто так - в свое время сталкивался краем уха с подобной системой.
Насколько помню - там все достаточно просто - есть некое средство
для построения функционала, которое банально не всегда строит нужніе индексі.

обновление статистики у вас идет долго, скорее за все потому, что ві віполняете на всю таблицу сразу а не на индексніе права.

Относительно емких статотчетов - пробовали ли смотреть плані запросов?
часто помогает, при чем вставляйте в sqexplain.out периодически запись со временем

Хотя на 11.50 смотрю "трассировку" (onstat -g his) - в некоторіх местах бред получается.

10Гб єто не БД для интел серверов за последние года 3.

vasilis
Да, 10Г для вашей системы многовато и, похоже, что опыта в решении проблем производительности для такой конкретной системы нет не только у вас.
Когда то уже пытались решать похожую задачу на верхнем уровне (общая БД в СЗ) и поняли - это система и проектировалась и разрабатывалась и настраивалась для работы на базовом уровне (до 50 пользователей и сотни метров оперативных данных). Системы с более тяжелой нагрузкой и объемами требуют других подходов. Изменить их, насколько я понимаю, проблематично и сейчас.

Так или иначе, но, довольно часто подобніе проблемі решаются не разработчиком а заказчиком собственніми силами.
Большинаство систем наверное так и проектируется, но время все расставляет на свои места.

Возможно, да, нету универсального способа решения проблемі, но можно найти частній, которій удовлетворит на 100% данного клиента.

Денис прав - нужно ріть в сторону запросов.

Если вдруг будете искать стороннего человека - пишите. (мой ник на gmail.com)

...

Рейтинг:

0 / 0

31.08.2009, 12:16

| Ответить | Цитировать | Написать

25 сообщений из 63, страница 2 из 3

все

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=44&msg=36168762&tid=1607756]:	0ms
get settings:	9ms
get forum list:	13ms
check forum access:	4ms
check topic access:	4ms
track hit:	61ms
get topic data:	11ms
get forum data:	18ms
get page messages:	54ms
get tp. blocked users:	1ms
others:	13ms

total:	188ms