- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
"Способы перехватить сисколлы в Linux" - как вариант - LD_PRELOAD, но тоже далеко не идеальное решение. Ранее были варианты перехвата в модулях ядра, но потом лавочку прикрыли во избежание. Проще патчить ядро, конечно же.
Но опять же, патч от BH безумно далеко от production ready и его нужно пилить_пилить_и_пилить перед использованием.
А тех, кто неторопливо бэкапит 400 гб ежесуточно - мне искренне жаль, отдавать огромный процент самого важного на хостинге ресурса - дисковой подсистемы - на задачу, которая далеко не основная на хостинге - это очень странно.
Pavel.Odintsov добавил 28-01-2011 в 02:17
Ну всё равно получается минимум - ребут в месяц. Это заведомые 5 минут дауна в месяц, что достаточно плохо.
Плюс, скорее всего, при тестировании на продакшене вылезет что-то достаточно нехорошее, что потребует ещё 5 минут перезагрузки.
Осознание этого в основном и останавливает от использования подобных фич на более-менее серьезном проекте. Хотя, может быть, начальство когда-нибудь созреет до необходимости инноваций.
Ну последнее время баги в ядре находят чаще чем раз в месяц, так что необходимость ребута с кастом ядром не сильно выше необходимости в ребуте обычных ядер при обновлении в репо (про без ребутовые апдейты я знаю, напоминать про них мне не нужно).
"Способы перехватить сисколлы в Linux" - как вариант - LD_PRELOAD, но тоже далеко не идеальное решение. Ранее были варианты перехвата в модулях ядра, но потом лавочку прикрыли во избежание. Проще патчить ядро, конечно же.
Крайне сомневаюсь, что "перекрыли" - Вас кто-то дезинформировал.
Вообще говоря, модуль ядра не сильно лучше патча. Ведь проблема в другом - что модуль, что изменения в патче работают в пространстве ядра. Шаг влево, шаг вправо, немытые руки - и получаем панику.
А тех, кто неторопливо бэкапит 400 гб ежесуточно - мне искренне жаль, отдавать огромный процент самого важного на хостинге ресурса - дисковой подсистемы - на задачу, которая далеко не основная на хостинге - это очень странно.
На основании чего Вы думаете, что "огромный"? И сколько в цифрах значит "огромность"?
Ну последнее время баги в ядре находят чаще чем раз в месяц, так что необходимость ребута с кастом ядром не сильно выше необходимости в ребуте обычных ядер при обновлении в репо (про без ребутовые апдейты я знаю, напоминать про них мне не нужно).
Смотрим DSA:
01.2011 - нет апдейта
12.2010 - нет
11.2010 - DSA-2126-1
10.2010 - нет
09.2010 - DSA-2110-1
08.2010 - DSA-2094-1
07.2010 - нет
06.2010 - нет
05.2010 - DSA-2053-1
...
Имеем четыре апдейта за 9 месяцев. Чуть реже чем раз в два месяца. Если не принимать во внимание того, что конкретный апдейт может и не быть необходимым: есть другие пути решения проблемы, Вы не используете уязвимый функционал (модуль ядра, например) и т.п.
Вы уверены, что понимаете, зачем есть журналируемые ФС?
Уверен. Я вам что хочу сказать - хостинг == надежность или хостинг != надежность? Ну можно научиться обрабатывать журнал ФС, там эти изменения хранятся, не в том виде, конечно, не в удобоваримом. Да, именно... Модуль - правильнее. Легче != правильнее.
Снижена производительность весь день, но она у меня величина постоянная. В отличии от тех, у кого в определенные часы дисковая подсистема просто трещит по швам ;). Это мой выбор.
Сейчас предлагаю не спорить больше в этом топике, тем более, что в теме была обвинена компания, которая оказалась практически невиновной. Апать такой заголовок не хорошо.
Ребят, мы общаемся. Щас вот меня вразумите - так я ж может встану на путь истинный и начну все что ни попадя пихать в ядро? И т.д. и т.п. А ISPSystem - они ко всему привычные...
Raistlin добавил 28.01.2011 в 06:04
дисковой подсистемы - на задачу, которая далеко не основная на хостинге - это очень странно.
Павел, у этого хостинга основная задача - сохранить данные клиента любой ценой (!), при этом не падая и ставя в максимум аптайм. Клиенты специфические есть, которые держат там довольно серьезные данные. Поэтому резервирование делается даже в несколько стран...
Raistlin добавил 28.01.2011 в 06:08
Т.е. я о чем... Когда хостер отключает акцесслоги нахрен для увеличения производительности (а встречаются чуда. что еще и еррорлоги выключают) - от тут начинаешь задумываться о смысле жизни... Нужен баланс, соотношение.
Павел, у этого хостинга основная задача - сохранить данные клиента любой ценой (!), при этом не падая и ставя в максимум аптайм.
Да, но когда сервер падает раз в несколько месяцев и при этом общий даунтайм минут 20, то это и есть надежность. А если Вы дерете ежесекундно свою дисковую систему, то у Вас вечный даунтайм получается.
>"Способы перехватить сисколлы в Linux" - как вариант - LD_PRELOAD, но тоже далеко не идеальное решение.
Ну, это фактически то же самое, что линковаться со своими open() и так далее. Всё равно остаётся проблема подсовывать это всем в env или патчить ld. Ну и проблема с количчетсвом логов и правами на них.
>Ранее были варианты перехвата в модулях ядра, но потом лавочку прикрыли во избежание. Проще патчить ядро, конечно же.
Действительно, sys_call_table больше не экспортируют :( Получается, остаются только совсем сумасшедшие кривости.
>Уверен. Я вам что хочу сказать - хостинг == надежность или хостинг != надежность? Ну можно научиться обрабатывать журнал ФС, там эти изменения хранятся, не в том виде, конечно, не в удобоваримом. Да, именно... Модуль - правильнее. Легче != правильнее.
Журналируемая ФС не записывает все происходящие изменения. То, что она записывает не имеет какого-то API и соглашений - всё остаётся на совести реализации. Так что перешли с ext3 на jfs или ext4 - переписываем нетривиальный модуль.
Вас вечный даунтайм получается.
Не ощущаю... Падает по другим причинам, но никак не из-за нехватки ресурсов дисковой подсистемы.
И это все ради бекапа? Детский сад какой-то.
Нормальные хостинги используют CDP.
Если Вы о Continuous_data_protection как технологии, то патч реализует почти это.
Если о решении от r1soft - то ещё нужно смотреть, насколько оно кривое и проблемное.
Не ощущаю... Падает по другим причинам, но никак не из-за нехватки ресурсов дисковой подсистемы.
Подождите. Клиентики на сервере поднаберутся, будет даунтайм сплошной. Уже после тысячного сайта будет видно. Даже после 800-го примерно. Все впереди. И рекомендую подготовиться к этому заранее.
Если Вы о Continuous_data_protection как технологии, то патч реализует почти это.
Если о решении от r1soft - то ещё нужно смотреть, насколько оно кривое и проблемное.
Год в продакшине CDP - 0% проблем.