The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от opennews (??) on 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

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "идиоты"  +/
Сообщение от Аноним (??) on 05-Май-09, 14:08 
Сравнили экспериментальную шнягу с продакшн релизом постгреса 8.3....
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от Avatar (??) on 05-Май-09, 14:23 
Моё отношение к MySQL это уже не изменит, я за Postgresql.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от Alexander (??) on 06-Май-09, 11:11 
А числовые unsigned-типы там принципиально не делают?
Только из-за unsigned-типов держу кое-какие базы в MySQL...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

5. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от igorsia on 05-Май-09, 16:15 
А что еще сломали?
в 5.1 в очередной раз сломали MyISAM. Починят (как всегда) через годик.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от pavlinux (ok) on 05-Май-09, 17:07 
SSD под SQL - кучеряво живут...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от TS on 05-Май-09, 17:33 
FusionIO под MySQL - вот это точно кучеряво живут. FusionIO стоят около $10K...
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от pavlinux (ok) on 05-Май-09, 18:07 
FusionIO: 160GB = 4800$.

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от mmm (??) on 05-Май-09, 19:04 
FusionIO - это разновидность SSD, только с другим (относительно того, к которому привыкло большинство) интерфейсом.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от User294 (ok) on 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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

))) смишной)

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

10. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от pavlinux (ok) on 05-Май-09, 18:12 
букашки, это граммы золота? SAS стоит 250$ и дальше.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от Ivan (??) on 05-Май-09, 21:38 
Надо полагать не хуже чем DB2.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от Аноним (??) on 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
как-то настораживает...

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

28. "Релиз MySQL 5.0.81. Заметки по производительности MySQL. Нов..."  +/
Сообщение от azz email on 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)


;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру