recentpopularlog in

oracle

« earlier   
Recuperar datos de un tiempo pasado en base de datos
-------------------------------------
--Recuperar datos de un tiempo pasado
-------------------------------------
select * from crpdta.f4105 AS OF TIMESTAMP TO_TIMESTAMP('2017-06-09 13:30:00', 'YYY...
oracle  database  recover  data  table  from notes
3 days ago by iteruel
About Pool Sizing
Configuring a connection pool is something that developers often get wrong. There are several, possibly counter-intuitive for some, principles that need to be understood when configuring the pool. Bottomline: the smaller your pool, the better. And use this formula: connections = ((core_count * 2) + effective_spindle_count)
oracle  databases  profiling  performance  threads  optimization  pool 
4 days ago by oscar-lopez
«20 тысяч IOPS на узел — хорошие показатели с учётом задержек в 5 мс». Для OLTP — нет / Хабр
Поводом написать эту статью стал весьма достойный обзор Как мы тестировали VMware vSAN... компании КРОК. Обзор-то достойный, но в нем есть фраза, с которой я борюсь уже больше десятка лет. Админы СХД, виртуализаторы и интеграторы раз за разом повторяют: "Задержки в 5 мс — это отличный показатель". Даже цифра в 5 мс десять лет не меняется. Я это слышал вживую от весьма уважаемых админов уже не меньше десятка раз. От менее уважаемых — десятки, а уж сколько раз читал в интернете… Нет, нет, нет. Для OLTP нагрузок 5 мс, особенно так, как их обычно измеряют — это epic fail. Мне приходилось объяснять причины этого уже много раз, на этот раз я решил собрать свои мысли в переиспользуемую форму.
...
Дисковая система куплена дорогая и, вроде даже как-то настроена.

Ан нет. Крокодил не ловится, не растет кокос, и производительность системы такая же или ниже чем на старом сервере. Смотрю в sys.dm_os_waitsats и вижу WRITELOG, PAGEIOLATCH_SH и PAGEIOLATCH_EX в топе, среднее время ожидания 5+ мс. Ну типично, чо: "Эй, админы и DBA, тут у вас дисковая система — bottleneck" и вот тут начинается старая песня про 5 мс:


У нас 5 мс по SLA
Да у нас полка 20000 IOPS тащит
Нам вендор сказал, что все файлы БД можно на один раздел
У нас виртуализация и гиперконвергентность и мы не можем выделять отдельные диски под БД
По нашим данным утилизация сервера 5%
Всё настроено по рекомендациям
Вашим БД не нужна большая производительность, она не делает больше 300 IOPS (а у нас же полка на 20000 IOPS)

Кстати, всё вышесказанное не только про "свои" сервера, но и про облачные сервисы и виртуализацию. Там есть кучка своей специфики, но типичная клиническая картина примерно та же: в меру оптимизированная БД, неглупые сотрудники разработки и сопровождения, по процессору и памяти резерв есть, "выхлоп" от дальнейших вложений почти равен нулю.


Так вот. Эта вся песня про "5 мс" чушь и ерунда. Если вы сами такое говорите — читайте эту статью. А если вам такое говорят — готовьте аргументы. Раньше, когда я слышал эти слова, я злился, но я уже не злюсь. У меня, как у того горшка с петуньей из "Автостопом по галактике" только одна мысль: "Ну вот опять...".
...
Для OLTP систем на разделе с WAL/журналами транзакций 5 мс это недопустимый показатель. На "почти-коммодити" железяке за цену в 1000 (прописью: в тысячу) раз дешевле нормальным показателем сейчас будет 0,1-0,3 мс. А завтра — 0,01 мс. Скорость, как у HDD 2008 года по цене целого подъезда квартир в Москве не нужна. Никакое "удобство обслуживания" этого не стоит.
Вендор пишет, что журналы транзакций не требовательны к IOPS и их можно положить на HDD? Да, это так. Но для этого надо чтобы эти диски ни одна зараза задача кроме записи журналов СУБД не трогала. И чтобы СХД отвечала серверу, что данные записаны, сразу как данные легли в энергонезависимую память (это гораздо раньше, чем они будут записаны)
"Тонкие" диски для реальных OLTP БД — зло.
Для WAL абсолютно неинтересно сколько там можно выжать IOPS на глубине очереди 10 или 20. Там нет глубины.
Для WAL абсолютно не показатель, что очередь IO в ОС "всего лишь около 1". Она не будет больше.
...
Средняя задержка на разделе с WAL никогда не будет в секунду больше транзакций, чем:
5 мс 200
1 мс 1000
0,5 мс 2000
0,1 мс 10000
0,05 мс 20000
...
Делить дисковое пространство на LUN — это не прихоть DBA. У базы данных есть несколько разных профилей нагрузки дисковой подсистемы. Как минимум можно выделить следующее:
...
Ознакомьтесь с рекомендациями производителя СХД и СУБД, постарайтесь разобраться "почему они так советуют" и спроектируйте систему с учетом разных видов нагрузки. Разнесите принципиально разные виды нагрузки на разные разделы.
...
Latency почти всегда важнее throughput. И это продолжает быть верным и в облачных технологиях, и в "гиперконвергентных системах", и виртуальных фермах. Если вы улучшаете throughput увеличивая latency, то скорее всего ошибаетесь. Такое делать можно только очень обоснованно.
...
На горизонте есть очень интересный новый участник борьбы за производительность систем хранения для БД. Это Intel Optane. У нынешних SSD "красивые" цифры производительности начинаются от глубины очереди 4, что на самом деле не очень жизненно. Плюс эта производительность на запись обеспечивается некоторым объёмом оперативной памяти внутри SSD, и, если запись идёт достаточно интенсивно, то потом наступает существенная деградация производительности. А еще у SSD ограничен ресурс. Да, у современных серверных и топовых "гражданских" он достаточно большой, но совсем не бесконечный. И тут на сцене появляется Intel Optane: судя по тестам несерверных моделей (раз, два ) задержки на случайных операциях на очереди глубины 1 выходят на уровень около 20 микросекунд. Это по сути без кеширования, без деградации. SSD при таком же профиле начинают тупить до 100-300 мкс. Ресурс уже сейчас выходит за типичный ресурс SSD.
Ну цена, да. Но потенциально эта железка открывает новые горизонты производительности OLTP "традиционной", не in-memory архитектуры без отказа от ACID. А с другой стороны latency 20 мкс заставляет задуматься о судьбе "обычных" СХД. На low-latency требованиях им будет очень тяжело конкурировать с Optane (снова привет встроенным системам хранения?).
Это всё очень круто и я надеюсь на успех (и подешевление) Optane.
...
Статья и да, и нет.

Да — если вы мне продадите устройства, у которых в fsync-режиме (iodepth=1, block=4k, random write 100%) гарантированная минимальная latency 5ms, я буду просто счастлив. Почему? Потому что на современных устройствах (SSD, NVME), пики в реальных бенчмарках оказываются в районе секунд, в идеальных случаях — в районе многих сотен милисекунд.

fsync — критическое. Например, первый попавшийся SSD диск выдаёт мне 50кIOPS на запись. sustained, iodepht=32, span=100%, randow write 100%, blocksize=4k.

Но стоит в конфиг теста написать fsync=1… [more]
vmware  vsan  benchmark  talks  storage  ssd  database  performance  oracle  optane 
8 days ago by some_hren

Copy this bookmark:





to read