> Не торопитесь говорить гоп. Вот одна из историй "успеха": >>Сервер мы собрали, Нексенту поставили. Поставили нам ее официальные партнеры Нексенты, сертифицированные инженеры. >>первый косяк мы словили уже через неделю — по мере миграции на Нексенте кончилась память для таблицы дедупликации. … на каждый блок ФС в пуле Нексенте надо примерно 500 байт в памяти для таблицы дедупликации. Если у нас в системе 128Гб памяти, Нексента может хранить инфу про 256 000 000 блоков: максимальный размер занятого пула на 4К блоках — 1Тб, на 16К блоках — 4Тб, на 32К блоках — 8Тб и на 64К блоках — 16Тб. Запишите это красным маркером на стене! Зайдете за границу и прощай премия =) >>Если не так задали размер блока в самом начале — ничто не поможет, кроме миграции на новый том с правильным размером. >>Еще про дедупликацию на блочном уровне. Это не работает, забудьте. >>Тут всплывает второй косяк, не описанный в маркетинговых материалах сразу. Стоит ZFS пулу заполниться, как он радикально деградирует по производительности. Более 30% свободного места это не бросается в глаза (но видно на графике), с 30 до 10% все работает раза в три медленнее, а если места становится менее 10% — все работает на порядок медленнее. > http://habrahabr.ru/company/hostkey/blog/179151/ > и это на нексенте. вот на линухе http://habrahabr.ru/post/153461/ А башкой поработать вообще - слабо? С какого перепугу система с идеологией CoW должна при таком заполнении сохранять производительность? И - насколько это лютый недостаток в условиях МАССОВОГО производства терабайтных винтов?
|