Владимир
у меня 13
Владимир
13 это как раз 8к
Владимир
2 в степени 13
Владимир
Владимир
а ОЗУ достаточно для арк кеша?
Dmitry
сотни гиг
Владимир
а вес постгрес директории дата?
Dmitry
да
Владимир
на ZFS, не на ext4
Владимир
у меня на ext4 более чем в два раза больше
Dmitry
если не путаю то что-то около 10ТБ
Владимир
юху)
Dmitry
сжатие да хорошо работало 60-70% от исходного обхема только оставалась
Владимир
весоменько))
Владимир
авто наверное с большой вероятностью выставит 9
Владимир
))
George
по крайней мере если не выставлять, то в инфе диска будет 0
Владимир
смотря что диск отдаёт о себе
да я сколько смотрю большинство отдают 512, хотя походу тьрындят)
George
да я сколько смотрю большинство отдают 512, хотя походу тьрындят)
hdd по крайней мере физический размер относительно адекватно отдают
George
ssd конечно же чушь дают
Владимир
сжатие да хорошо работало 60-70% от исходного обхема только оставалась
а дедупликацию не включал?))
Иван
сжатие да хорошо работало 60-70% от исходного обхема только оставалась
Странно, а у нас обычно около того:
compressratio 3.39x
Владимир
Странно, а у нас обычно около того:
compressratio 3.39x
там в постгресе есть какой-то параметр который заставляет жать данные прям на уровне БД
Владимир
может у них это включено
Владимир
тогда прирост будет не такой ощутимый
Иван
Это в пг про энтерпрайз
Владимир
Это в пг про энтерпрайз
я даже не в курсе), так просто мельком слышал)), ну кстати у них с таким объёмом бд легко может быть ынтерпрайс))
Владимир
а дедупликацию не включал?))
это я написал не потому что надо включать)), а как раз наоборот)
Владимир
Владимир
не буду ковыряться))
Иван
))
Ivan
годно. в закладки)
мне непонятно зачем они переопределили размер блока на ссд в 4К, при этом в zfs выбрали ashift=13. какой с этого может быть профит ?
Сергей
мне непонятно зачем они переопределили размер блока на ссд в 4К, при этом в zfs выбрали ashift=13. какой с этого может быть профит ?
ну видимо на носителе 8к недоступно. А то так бы и там сделали. Базовые 512байт -> 4k
Ivan
ну видимо на носителе 8к недоступно. А то так бы и там сделали. Базовые 512байт -> 4k
results strongly suggest that the internal sector size is 8KB.
Ivan
тогда непонятно зачем интел так делает )
Сергей
results strongly suggest that the internal sector size is 8KB.
ну это предположение. А утилитой управления носителем нельзя сделать 8к., поэтому сделали 4к
list the sector size options for the P4610 model we use, but scanning it showed us two possible values: 0 (512B) or 1 (4KB)
George
мне непонятно зачем они переопределили размер блока на ссд в 4К, при этом в zfs выбрали ashift=13. какой с этого может быть профит ?
nvme умеет переключать размер сектора, у их дисков это 512б и 4к, на 4к объективно они будут быстрее
George
т.е. сама прошивка nvme каким блоком публично оперирует
Сергей
в прицнипе писать по 2 блока в 4к всяко лучше чем 16 блоков по 512байт
George
так что у кого nvme - обязательно проверяйте какие размеры сектора она умеет предоставлять и ставьте нужный
Сергей
@gmelikov, ничего свежего для оптимизации работы с нвме не завезли?
George
@gmelikov, ничего свежего для оптимизации работы с нвме не завезли?
пока нет, в целом оптимизации вливаются. Для нвме честный direct-io на горизонте маячит
George
nvme умеет переключать размер сектора, у их дисков это 512б и 4к, на 4к объективно они будут быстрее
вот тут в офиц доке кстати описывали это https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Hardware.html#nvme-low-level-formatting
Dmitry
продолжая вчерашний вопрос про getrusage, что она возвращает для zfs. чтения попадают в перемнную ru_inblock, это именно физические чтения (/ The numbers Fa ru_inblock and Fa ru_oublock account only for real I/O; data supplied by the caching mechanism is charged only to the first process to read or write the data.), подскажите пожалуйста есть лик акой-то просто способ проверить что для zfsэто работает также (чтение из arc не считаются)
Ivan
blktrace скорее всего поможет разобраться
George
продолжая вчерашний вопрос про getrusage, что она возвращает для zfs. чтения попадают в перемнную ru_inblock, это именно физические чтения (/ The numbers Fa ru_inblock and Fa ru_oublock account only for real I/O; data supplied by the caching mechanism is charged only to the first process to read or write the data.), подскажите пожалуйста есть лик акой-то просто способ проверить что для zfsэто работает также (чтение из arc не считаются)
можно убедиться через arcstat что чтение идёт с arc чисто, и посмотреть меняется ли это значение на ручных тестах. Ну и iostat в помощь тоже
Dmitry
спасибо!
nagual
Приветствую. Есть 6 дисков по 1Т что лучше сделать ?
Иван
Я бы продал и пропил.
Иван
Приветствую. Есть 6 дисков по 1Т что лучше сделать ?
Для чего предполагается использовать? Какой профиль нагрузки?
nagual
Критические данные, бакапы ...
nagual
Ещё есть ssd 1T
nagual
А если важна ?
Иван
До этого сервера с бэкапами линк 1G?
nagual
Хочется 10G
Dmitry
можно убедиться через arcstat что чтение идёт с arc чисто, и посмотреть меняется ли это значение на ручных тестах. Ну и iostat в помощь тоже
я же правильно интерпретирую, что если во время выполнения запроса в базе arcstat hit% выдает 100, значит все чтения идут из arcа не с диска?
nagual
любое четное количество
А если туда парочку SSD небольшого размера добавить это позволит использовать ZRAID2 и всё же получить достаточную скорость ?
Konstantin
nagual
А вот восстановление из бакапа было долгим ...
Konstantin
Ничего не понятно, но интересно)
nagual
Там канал 3G
nagual
Скорость чтения записи около 250 Мег/с
George
я же правильно интерпретирую, что если во время выполнения запроса в базе arcstat hit% выдает 100, значит все чтения идут из arcа не с диска?
Да, перепроверьте просто с показателями iostat дисков
Dmitry
вдруг это кому нужно будет, getrusage интерпретирует чтения из arc как чтения с диска (физические), т.е. использовать ее для разделения чтений с диска и из памяти как в случае с page cache (ext4) не получается