Комментарии 34
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
коммит подразумевает, насколько я знаю, не только изменения в журнале, но и в самой БД. А как с ними?
НЛО прилетело и опубликовало эту надпись здесь
Это методы снижания нагрузки на диски. Меня же интересует, скорее, вопрос рассчёта нагрузки. Потому что я сейчас (уже третий день с этой темой вожусь), понимаю, что на самом деле никто реально не может эту нагрузку рассчитать, и все уповают на то, что «авось, хватит».
НЛО прилетело и опубликовало эту надпись здесь
Ну, давайте поиграем в ТЗ.
ОС: Linux/Windows (пишу оба варианта, выбирайте какой приятнее)
Соединение с сервером: SAS
Диски: Около 50 SATA дисков в корзинах.
Набор стандартных операций пользователя: офисная работа, размер открываемых файлов неопределён (какой пришлют прайс, такой и будет).
SQL-база, допустим (на ваш выбор): MSSQL+1C, MYSQL+SUGARCRM.
Количество пользователей — от 30 до 50
Функции построения отчётов: отчёт о продажах с такого-то по такое-то, отчёт о закупках, обороты, кассовые отчёты за произвольные интервалы времени.
Характер базы, допустим, 'mixed', хотя я осмысленно на этот вопрос ответить не могу.
ОС: Linux/Windows (пишу оба варианта, выбирайте какой приятнее)
Соединение с сервером: SAS
Диски: Около 50 SATA дисков в корзинах.
Набор стандартных операций пользователя: офисная работа, размер открываемых файлов неопределён (какой пришлют прайс, такой и будет).
SQL-база, допустим (на ваш выбор): MSSQL+1C, MYSQL+SUGARCRM.
Количество пользователей — от 30 до 50
Функции построения отчётов: отчёт о продажах с такого-то по такое-то, отчёт о закупках, обороты, кассовые отчёты за произвольные интервалы времени.
Характер базы, допустим, 'mixed', хотя я осмысленно на этот вопрос ответить не могу.
возможно размер слайса должен быть кратен размеру IO буфера для улучшения производительности?
А какой смысл в использовании RAID60 на 22дисках? Для ряда задач, это будет совершенно необоснованное избыточное хранение данных…
Если скорость хоть одного винчестера ниже стандартной — скорость всего рейда будет ниже.
В нормальных аппаратных рейдах, например 3ware, можно в реалтайме видеть IOPS для каждого из дисков, входящих в массив.
В нормальных аппаратных рейдах, например 3ware, можно в реалтайме видеть IOPS для каждого из дисков, входящих в массив.
Если у вас слайс 16к и вы хотите записать 4М — это затронет 256 стрипов.
в вашем случае — почти все винты.
почти все винты будут позиционировать головы туда-сюда туда-сюда…
ужас…
варианты решения
1.контролер с хооооорошеньшим буфером, и мозгами.
чтобы нормально оптимизировал очереди, и винды, даже при рандом аксесе, действовали внятно
2.увеличивать размеры стрипов
3.как вариант — поднять несколько различных рейдов\групп и ид, чтобы одни таблицы читались с одного набора винтов, а другие — с других.
4.сказать что вам важнее — скорость чтения одного файла или IOPS — ведь можно построить систему которая будет быстро обслуживать одного клиента, а можно постоить так чтобы обслуживало конечно сильно медленее, но десяток тысяч( первая система в этом вариант встанет раком )
хотя это все софистика, 90% решает контролер, остальные 10% — разложения данных по «полочкам»
в вашем случае — почти все винты.
почти все винты будут позиционировать головы туда-сюда туда-сюда…
ужас…
варианты решения
1.контролер с хооооорошеньшим буфером, и мозгами.
чтобы нормально оптимизировал очереди, и винды, даже при рандом аксесе, действовали внятно
2.увеличивать размеры стрипов
3.как вариант — поднять несколько различных рейдов\групп и ид, чтобы одни таблицы читались с одного набора винтов, а другие — с других.
4.сказать что вам важнее — скорость чтения одного файла или IOPS — ведь можно построить систему которая будет быстро обслуживать одного клиента, а можно постоить так чтобы обслуживало конечно сильно медленее, но десяток тысяч( первая система в этом вариант встанет раком )
хотя это все софистика, 90% решает контролер, остальные 10% — разложения данных по «полочкам»
Рейд 5 и 6 по определению медленные на запись.
НЛО прилетело и опубликовало эту надпись здесь
Любопытно, но пока у меня такая статистика:
блоки: рандом от 4к до 4Мб
Слайсы по 16к — 113875кб/с запись, слайсы по 512к — 77031кб/с. Это тест по 256Гб данных. Насколько я понимаю, ключевым тут является то, что при записи 4к в 512 слайс, его приходится пересчитывать весь (читать и писать обратно).
Сейчас доходит тест с 64к слайсами…
блоки: рандом от 4к до 4Мб
Слайсы по 16к — 113875кб/с запись, слайсы по 512к — 77031кб/с. Это тест по 256Гб данных. Насколько я понимаю, ключевым тут является то, что при записи 4к в 512 слайс, его приходится пересчитывать весь (читать и писать обратно).
Сейчас доходит тест с 64к слайсами…
Потестируйте софтовый md-raid в линуксе, думаю вас сильно удивят результаты.
НЛО прилетело и опубликовало эту надпись здесь
я вообще не понял, зачем ты писал пост.
очевидно же, что значения «максимальный иопс» не существует.
скорее интересен вариант макимум иопсов с диска при латентности до XX милисек.
вот это уже можно померять, но лучше воспользоваться табличкой от поставщиков сан-решений, который посчитали это уже очень давно: «SAS 15k — 180, SAS 10k — 140, SATA 7200 — 80, SATA 5400 — 40»
очевидно же, что значения «максимальный иопс» не существует.
скорее интересен вариант макимум иопсов с диска при латентности до XX милисек.
вот это уже можно померять, но лучше воспользоваться табличкой от поставщиков сан-решений, который посчитали это уже очень давно: «SAS 15k — 180, SAS 10k — 140, SATA 7200 — 80, SATA 5400 — 40»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
IOPSы