michaek, спорьте с OpenVZ разработчиками - http://openvz.org/Kmemsize#kmemsize, мы-то тут при чем?
michaek, 67 мегабайт kmem памяти при лимите в 400 процессов - это 170 килобайт памяти на процесс, в среднем же процесс потребляет около 60 (опять же, с вики openvz), подавляющему большинству этого предостаточно.
К сожалению, для избежания проблем у других соседей, мы не можем выдавать слишком много kmem памяти, ее переполнение - явный звоночек на апгрейд тарифа до FPS/выделенного сервера либо глубокую оптимизацию.
А по поводу этого самого gap...мы никогда не сталкивались с тем, что это может вызвать реальные проблемы, openvz просто выдает ошибку форка и ничего не убивает. Если у Вас иные подтвержденные данные - мы рассмотрим вопрос об изменении параметров, но в данный момент я не вижу в этом проблемы.---------- Post added 03-03-2013 at 22:22 ----------
Честно говоря, не совсем понял суть Вашего вопроса, но попробую ответить.
Для мониторинга нагрузки на сеть мы рекомендуем использовать либо iftop либо ifstat, оба приложения отображают текущую нагрузку на сеть.
michaek, что именно Вас смущает - размер лимита или их эквивалетность? То, что размер фиксирован - это наше ограничение, что эквивалетны - никогда не замечали описанного у openvz поведения процессов, которое может вызвать их эквивалентность.
В любом случае смотрите в сторону выделенных машин/понижения числа процессов в системе.
netwind, я всегда восхищаюсь, когда техническое предположение попадает в точку :) Вы угадали во всех случаях, я могу лишь согласиться и ничего не добавлять к сказанному Вами.
michaek, job@fastvps.ru, здесь обсуждение будет офтопом.
К сожалению, сейчас никак не улучшить пинг - проблемы на сопряжении внешних магистралей. Но в ближайший месяц у нас будет прямое подключение к М-9 (г. Москва), что должно серьезно улучшить доступность и радикально понизить пинг.---------- Post added 24-02-2013 at 00:52 ----------michaek, конкретно предложенный Вами метод позволит выиграть максимум секунд 70, но он серьезно усложняет обслуживание сервера и усложнит бэкап скрипты на порядки (и, разумеется, повысит вероятность ошибки при съеме бэкапа). И, к слову, такой вариант был указан в моей заметке как применимый в более сложных случаях.
По поводу вакансии - именно эта вакансия, все знания сверх - огромный плюс и всячески поощряются :)
ха, понизить :) Сменить датацентр - единственный вариант.
Добавлять latency (задержку) к любому типу пакетов умеет iproute2, вот пример: http://superuser.com/questions/444491/tc-iproute2-with-random-delay-per-flow
Но для этого нужен дедик или VPS c полной виртулизацией, например, на openvz не уверен, что это будет работать.
Предложите лучший гарантированно консистентный и более быстрый способ полного резервирования MYISAM базы данных и мы с радостью его примем как лучший и заменим ныне используемый.
michaek, Вы очень внимательны и хорошо осведомлены технически, мы были бы рады рассмотреть Вас как претендента на вступление в нашу замечательную команду http://job.fastvps.ru :)---------- Post added 23-02-2013 at 13:59 ----------
На ряде серверов их можно поставить. Если Вам это критично - можем перенести/установить Ваш контейнера на данных серверах. Проблема тут не в отсутствии образа, а в том, что они некорректно работают с используемой нами версией openvz.
Добрый день!
Обычный бэкап осуществляется именно по такой схеме, но это не единственный механизм резервирования, всего их три и работают они совместно.
Вопрос предельно прост - дайте возможность бесплатного апгрейда для владельцев вечных лицензий. Иначе выпуск продукта со схожим названием и с отказом в стиле "это же другой продукт" выглядит несколько странно и возникают подозрения, что цель не в новом продукте, а в выбросе кучи вечных лицензий и получении денег вновь и вновь.
А в данном конкретном случае меня волнует лишь то, что поддержка отказалась фиксить критичный для нас баг ссылаясь на то, что продукт закрыт и теперь будет другой. Это основной источник моего недовольства.
