|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день,
возникла потребность в высвобождении памяти в уже активно работающем кластере. Разработчики обещают 50%+ сжатие после активации необходимых настроек (CompressedBackup + CompressedLCP) , что и было сделано. Далее, согласно инструкции, ноды заребутили - 0 ноль реакции. Ребутнули с инишиалом - ноль реакции.
Как вообще заставить компрессию сжать уже существующие данные?
Спасибо!
ps - ноды которые бутались это датаноды + управляющая + майсиквел.
Отредактированно ndb (12.04.2012 14:07:55)
Неактивен
Никто не может помочь советом? (
Неактивен
Эта опция точно включена на всех датанодах? По описанию вы все делаете правильно.
Неактивен
rgbeast написал:
Эта опция точно включена на всех датанодах? По описанию вы все делаете правильно.
Что значит "включена на всех датанодах" ?
Был скорректирован конфиг управляющей ноды, активированы нужные параметры (привел их выше). Далее ноды были перезагружены, в том числе и с initial. В итоге юз рамы не уменьшился.
Мы что-то упускаем?
Спасибо, очень жду ответа.
Может, вас можно попросить написать пошаговый алгоритм реализации компрессии?
Отредактированно ndb (13.04.2012 19:44:54)
Неактивен
ndb написал:
Был скорректирован конфиг управляющей ноды, активированы нужные параметры (привел их выше). Далее ноды были перезагружены, в том числе и с initial. В итоге юз рамы не уменьшился.
Мы что-то упускаем?
Видимо упускаете то, что данные опции не должны приводить к экономии оперативной памяти. Они предназначены для сжатия файлов на диске (local checkpoint files и backup files).
Неактивен
rgbeast написал:
ndb написал:
Был скорректирован конфиг управляющей ноды, активированы нужные параметры (привел их выше). Далее ноды были перезагружены, в том числе и с initial. В итоге юз рамы не уменьшился.
Мы что-то упускаем?Видимо упускаете то, что данные опции не должны приводить к экономии оперативной памяти. Они предназначены для сжатия файлов на диске (local checkpoint files и backup files).
теперь все ясно, спасибо(
Неактивен
Тогда встречный вопрос: есть возможность хранить часть данных на диске, а не в раме. Насколько сильно это убивает производительность? Как организовать перенос данных без остановки работы кластера?
Я прошу прощения, если мои вопросы кажется вам нубскими - только разбираемся.
Неактивен
Да, можно хранить данные на диске (при этом все индексы всё равно будут в ОЗУ):
http://dev.mysql.com/doc/refman/5.1/en/ … jects.html
Неактивен
Еще вопрос:
1) удаляем из таблицы 20% данных.
2) оптимизацию сделать нет возможности - из-за размера таблиц виснет(
3) ребутаем ноду - спад использования рамы только 1%
Данные удаляем не полной очисткой а делитом. заметили, что если очищать таблицу полностью - кластер пересчитывает корректно.
Вопрос: как заставить таблицы весить корректно после удаления части данных и тем самым немного высвободит памяти?
Неактивен
Кластер так устроен, что рестарт восстанавливает ту же структуру данных в памяти, которая была. Дефрагментация при этом не происходит.
Новые данные в таблице будут вставляться в свободные области, так что память не потеряна безвозвратно.
Неактивен
Уточню, что сейчас юз рамы 90%+
При запуске оптимизации больших таблиц создаются очереди входящих, нагрузка на кластер возрастает и все виснет к чертям. Ребут, как я писал выше, не спасает.
Посоветуйте что нибудь, не хочется еще 2 сервера покупать 
Удалением данных, в теории, мы сняли данных до 80-85% рамы, но вот высвободить ее не получается(
Неактивен
rgbeast написал:
Кластер так устроен, что рестарт восстанавливает ту же структуру данных в памяти, которая была. Дефрагментация при этом не происходит.
Новые данные в таблице будут вставляться в свободные области, так что память не потеряна безвозвратно.
просто у нас при 93% загрузки памяти начинает подлагивать обработка данных. Данные чистим, оптимизацию сделать не можем. Замкнутый круг(
Неактивен
Купить еще памяти как вариант не подойдет?
Неактивен
