URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 53817
[ Назад ]

Исходное сообщение
"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."

Отправлено opennews , 05-Май-09 14:08 
Вышел (http://permalink.gmane.org/gmane.comp.db.mysql.announce/478)  релиз MySQL Community Server 5.0.81 (http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-8...), список изменений насчитывает исправление более 100 ошибок из которых 30 приводили к краху серверного процесса, а 2 ошибки были связаны с исправлением проблем безопасности. Но при внимательном рассмотрении большинство записей в списке изменений совпадают с изменениями в релизах 5.0.77 (http://www.opennet.me/opennews/art.shtml?num=20348) и 5.0.75 (http://www.opennet.me/opennews/art.shtml?num=19512), при выборке из репозитория исходных текстов обнаружено около 20 исправлений. Загрузить (http://dev.mysql.com/downloads/mysql/5.0.html) новую версию можно в исходных текстах и в виде бинарных сборок для всех популярных платформ.


Несколько новых заметок по MySQL:

-  "RAID vs SSD vs FusionIO (http://www.mysqlperformanceblog.com/2009/05/01/raid-vs-ssd-v.../)" - результаты сравнения производительности MyS...

URL: http://permalink.gmane.org/gmane.comp.db.mysql.announce/478
Новость: http://www.opennet.me/opennews/art.shtml?num=21601


Содержание

Сообщения в этом обсуждении
"идиоты"
Отправлено Аноним , 05-Май-09 14:08 
Сравнили экспериментальную шнягу с продакшн релизом постгреса 8.3....

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено Avatar , 05-Май-09 14:23 
Моё отношение к MySQL это уже не изменит, я за Postgresql.

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено Alexander , 06-Май-09 11:11 
А числовые unsigned-типы там принципиально не делают?
Только из-за unsigned-типов держу кое-какие базы в MySQL...

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено olex , 05-Май-09 14:30 
TokuDB проблемы:
1 TokuDB плохо масштабируется - плохо работает на многопроцессорных системах
2 INSERT и DELETE работают быстро, UPDATE - медленнее
3 пока что нет recovery logs

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов"
Отправлено open , 05-Май-09 16:09 
про ставбильность MySQL можно анекдоты сочинять)
http://sql.ru/forum/actualthread.aspx?tid=660905
раз в неделю подобные темы...
как только мы у нас не перегружали PgSQL
от питания до kill -9
Хранилище не бьется,
в отличии от MySQL у которого на ровной дороге,
Got error from table handler и досвидания...



"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов"
Отправлено geekkoo , 06-Май-09 06:35 
Можно не сочинять. Цитата -
"Венда ХР СП2 ... была открыта база в dbForge я играл в ViceCity и комп повис, ребутнул его кнопкой Reset" и уже смешно.

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено igorsia , 05-Май-09 16:15 
А что еще сломали?
в 5.1 в очередной раз сломали MyISAM. Починят (как всегда) через годик.

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено pavlinux , 05-Май-09 17:07 
SSD под SQL - кучеряво живут...

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено TS , 05-Май-09 17:33 
FusionIO под MySQL - вот это точно кучеряво живут. FusionIO стоят около $10K...

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено pavlinux , 05-Май-09 18:07 
FusionIO: 160GB = 4800$.

Я к тому, что SSD дохнут как мухи, а FusionIO 24 года, при трафике 5Тб в день.


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено TS , 05-Май-09 18:15 
>FusionIO: 160GB = 4800$.
>
>Я к тому, что SSD дохнут как мухи, а FusionIO 24 года,
>при трафике 5Тб в день.

А 5k$ - это не кучеряво? :)


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено mmm , 05-Май-09 19:04 
FusionIO - это разновидность SSD, только с другим (относительно того, к которому привыкло большинство) интерфейсом.

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено User294 , 05-Май-09 21:39 
>FusionIO - это разновидность SSD, только с другим (относительно того, к которому
>привыкло большинство) интерфейсом.

Кстати говоря - представлять flash-диски как якобы-HDD, с якобы-секторами в 512 байтов, с сокрытием реальной физики флеша и прочая - очень идиотская идея на самом деле, т.к. чертовски усложняет оптимизацию по скорости.Благо, *реальная* физика флеша здорово отличается и ничего общего с 512 байтными секторами не имеет.Запись именно блока в 512 байтов - это в случае NAND гарантированный влет на тормознутый read-modify-write силами его встроенного контроллера, который в ответ на такой запрос внутри себя вот такую вот последовательность действий отпедалит. Соврав всем что это запись 1 512 байтового сектора, просто такая вот медленная.На самом деле это как минимум чтение 2 или сколько там Кб страницы, патч 512 байтов, в лучшем случае - запись.В хучшем это вообще erase целого eraseблока+только потом запись(страницы можно писать только последовательно и фиг его там знает, выполнится ли это условие или нет).Чего доброго запись будет даже более чем 1 страницы даже (если на стертом erase-блоке было не пусто+в зависимости от логики FTL).И все это будет отпедалено ради якобы-атомарной записи 512 байтов!Пи$#ец...

ЗЫ: кстати браво форматируя штукенции с флешом не стоит забывать что всего лишь небольшая лажа в формате aka выбор размещения структур наобум и ... можно просрать скорость В РАЗЫ.Если скажем блоки ФС придутся на границу страниц флеша так что на чтение\запись 1 блока ФС будет вместо 1 страницы читаться\писаться 2 - выйдет жутко неоптимально и скорость весьма хардкорно просядет.Кстати если обратить внимание - дефолтовая ФС на продаваемых картах памяти, флехах и прочая как правило очень своеобразно скроена.Она там неявно и втихаря подогнана под физику флешатины, так что блоки ФС (у фат - кластеры) не попадют на середину границы страниц.А служебные структуры (mbr, таблицы FAT) сделаны так что во первых, MBR живет в отдельном erase block (и поэтому никогда не попадает под read-modify-write логику и потому не может слететь при проблемах), во вторых FAT'ы выравнены на erase-block, и так далее.

Ни один "обычный" форматтер ни в 1 ос этим не заморачивается и потому при попытке переформатить флеш-диск (как минимум для usb-флех верно) или MMC\SD карту - можно получить очень говняный результат. Кому интересно - подробный гайд по ускоренному убиению и деградации флешек - воон там: http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

P.S. а кто чувствует себя реально крутым и понимает как устроена та или иная ФС и как работает флеш - u're welcome: предлагается подумать над интересным вопросом: как оптимально разложить на флеш что-то более вменяемое чем дефективный и морально устаревший FAT32.Для FAT32 на вон той паге есть пример того как мануфактуреры флешек его раскидывают с оптимизацей под флеш.Ну как, а нам слабо что-то помощнее оптимально раскинуть?Я уже мозг над этим изрядно поломал.А вы?Да, производитель кстати может читерствовать: ему известна логическая организация чипаков флеша и логика работы FTL-уровня в контроллере.Нам остается только *гадать* на эту тему.Хотя на самом деле - можно произвести серию бенчмарков и на их основании прикинуть реальную структуру по их итогам (если записи хреново накладываются на структуру флеша - будет тормозно, если хорошо - будет быстро).

P.P.S. Кстати пользуясь случаем передаю привет цыркачу iZEN по части "оптимизации под флеш память".Теперь доходит что такое *настоящая* оптимизация файловой системы под флеш? :D. Грамотно положив лэйаут ФС на страницы и erase блоки можно достичь оптимальности в плане отсутствия лишней работы для контроллера флехи и минимума перезаписей из возможного.Вот за контроллер и сокрытие им структуры флеша хочется их всех слегка убить.Заметили насколько усложняется оптимизация из-за поддержки совместимости с механическими хардами на уровне логической организации?Суки.Надо ж так прогресс тормозить ради совместимости.

Regards, your Captain Obvious :D


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено x11term , 06-Май-09 06:15 
...
>Суки.Надо ж так прогресс тормозить
>ради совместимости.
>
>Regards, your Captain Obvious :D

Ты ещё x86 вспомни ...


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено Аноним , 06-Май-09 15:10 
>с механическими хардами на уровне логической организации?Суки.Надо ж так прогресс тормозить
>ради совместимости.
>
>Regards, your Captain Obvious :D

ужас-ужас!!!
как все плохо)))
если не помнить, о том, что на ssd есть кэш и как правило от 64Мбайт.
и контроллеры как правило оптимизированы, под то что бы не перезаписывать, пока есть возможность сделать переалокацию )))


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено User294 , 07-Май-09 13:38 
>если не помнить, о том, что на ssd есть кэш и как правило от 64Мбайт.

Только на хороших.На всяких там usb и прочая - такого нету.И кроме того - и на много его хватит при рандомных доступах по всей поверхности?У флеша seek time мелкий а потому в случае крутого диска есть соблазн наподдать ему параллельных запросов в разные участки, с этим как раз у механики проблемы.А вот тут то и будет опа.ФС считают что писать кусочками по 512 байтов в рандомные точки - вполне валидно в принципе.А то что это очень не здорово для носителя они могут и не знать.И не знают.Ну а уж о том чтобы выровнять структуры ФС на erase-block'и сэкономив флешу циклы перезаписи (и время на них) и подавно в обычном случае никто не думал.У жестких дисков то ничего такого нет.А большинство ФС делались именно под них.А контроллер скрывая детали физики флеша еще и делает такое выравнивание весьма негарантированной и нетривиальной операцией - кто ж документирует физическое устройство диска и как себя контроллер ведет там внутри?

>и контроллеры как правило оптимизированы, под то что бы не перезаписывать, пока
>есть возможность сделать переалокацию )))

Опять же - только хорошие контроллеры.Их таких не так уж много.И стоят диски от приличных производителей с таким контроллером - как задняя часть самолета.Зато всякого фуфла с примитивными контроллерами - навалом.Кроме того - опять же а как преаллокация переживает слет питания?Она логику журналирования не рушит?Журнал предполагает что если сказали нечто записать - это записано.А не то что железка где-то внутри себя будет ждать - а не допишут ли еще чего туда же.И, собственно, ФС в своем праве уповать на 512-байтные блоки.Или на что там еще.Не выровненое на страницы и erase-блоки, что было бы наиболее оптимально для флеша.


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено anonymous , 06-Май-09 15:48 
Кошмар как страшно.
Просветите нас темных.Команда dd, mkfs, format - обращаются напрямую к контроллеру flash, т.е прямо ему сообщают от по такому адресу проведем границу сектора. По его внутренним командам?
Или они работают через интерфейс неважно какой. USB, SATA, PCI(семейство)?

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено anonymous , 06-Май-09 16:01 
.... А дальше контроллеру устройства? Черещ интерфейс устройства?

(Ps. виноват.не дописал)


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено Аноним , 06-Май-09 19:03 
>Кошмар как страшно.
>Просветите нас темных.Команда dd, mkfs, format - обращаются напрямую к контроллеру flash,
>т.е прямо ему сообщают от по такому адресу проведем границу сектора.
>По его внутренним командам?
>Или они работают через интерфейс неважно какой. USB, SATA, PCI(семейство)?

))) смишной)

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


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено User294 , 07-Май-09 13:28 
> Команда dd, mkfs, format - обращаются напрямую к контроллеру flash

Нет, конечно.Вот только проблема в том что они работают с этим флешом как с обычным носителем.Как будто бы у него 512-байтные сектора которые можно индивидуально адресовать и записывать.А по факту - никаких секторов в 512 байтов там нет.Изображаются варварской эмуляцией путем read-modify-write страницы (которая у нанда обычно 2 или 4 Кб например).При этом операция получается не только не атомарной - она еще и соседние сектора затрагивает.Потому что у нанда атомарные операции - только со страницами, никак не менее.А это более чем 512 байтов.На что софт не рассчитывает в общем случае.Могу себе представить ситуацию когда питалово слетит так что это будет в процессе read-modify-write и похерится не только записываемый сектор (на что софт вполне может рассчитывать) но и несколько соседних (на что софт ессно не рассчитывает, т.к. у обычных жестких дисков запись сектора в принципе атомарная операция и соседние сектора обычно никак не затрагивает). Получается и более тормозно чем могло быть и стремно.А обычные файловые системы раскидывают по дефолту структуры как угодно, только не так как это было бы удобно реальному физическому носителю.


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено Поэт битов и байтов , 05-Май-09 18:07 
Я три года назад заюзал для сервиса типо DNSBL'a - всё просто взлетело но стоил 8GB дисочек 8 же тонн 8-\
А теперь - 120 букашек :) Так что не - не кучеряво, скучно и обыденно живут :)

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено pavlinux , 05-Май-09 18:12 
букашки, это граммы золота? SAS стоит 250$ и дальше.

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено User294 , 05-Май-09 21:11 
> К сожалению исходные тексты TokuDB не открыты для публичного доступа.

Началось... и как это согласуется с GPL'ем? oO


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено Ivan , 05-Май-09 21:38 
Надо полагать не хуже чем DB2.

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено Аноним , 06-Май-09 15:20 
ребят просветите, кто РЕАЛЬНО понимает как это работает

в тесте
"MySQL Performance: MySQL 5.4 and other InnoDB engines @dbSTRESS Benchmark"
приведен конфиг постгре с такими параметрами
effective_cache_size = 48000MB    
shared_buffers = 24000MB

это вообще считается нормальным?
(особенно при 256GB RAM)


да и вот это
fsync = on
synchronous_commit = off
wal_sync_method = fdatasync
wal_buffers = 2MB
как-то настораживает...

или это нормально и так и должно быть?
я действительно плохо понимаю какое должно быть соотношение ворк_мем/кэш/буферс


"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Отправлено azz , 07-Май-09 10:42 
В
http://dev.mysql.com/doc/refman/5.0/en/releasenotes-cs-5-0-8...

For InnoDB tables, ORDER BY ... DESC sometimes returned results in ascending order. (Bug#37830)


;)