- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Привет,
может быть у кого-то был такой опыт или у меня параноя ;)
Вообщем поанализировал немного работу нескольких серверов и пришел к выводу, что основную нагрузку создаёт I/O и в большинстве случаев - это mysql.
Решил провести эксперемент:
сделать софтварный рейд 1
1 диск - это рам диск
2 диск - это кусок обычного HDD
т.е. в случае ребута, данные всё равно остаются на HDD, а когда сервер поднимается, то происходит достаточно быстрый ребилд, т.к. скорость доступа к RAM высокая, а mysql в среднем занимает до 1GB и процесс займёт менее 1 минуты, после чего рестарт мускуля и чек баз.
Кто что думает по этому поводу?
p.s. может пора менять траву?
Не, трава хорошая, надо проверить, а по какой методе кусок диска + кусок памяти собраны в рейд?
Не, трава хорошая, надо проверить, а по какой методе кусок диска + кусок памяти собраны в рейд?
блок-девайсы
это пока теоретические предположения
Другой вопрос по какой методе они будут синхронизироваться при том, что обычный диск будет в несколько раз отставать в записи по сравнению с RAM.
Другой вопрос по какой методе они будут синхронизироваться при том, что обычный диск будет в несколько раз отставать в записи по сравнению с RAM.
Да это как раз не проблема на сколько я понимаю, все равно быстрее чем сможет диск данные на массив поступать не будут.... Да и данных там судя по посту ТС-а около 1 GB В памяти висит...
Romka_Kharkov добавил 16.11.2010 в 13:08
блок-девайсы
это пока теоретические предположения
Ну надо практические части осваивать наверное ))) задумка интересная.
Тогда и алгоритм зеркалировния до кучи писать придется. Уткнется то всё в скорость hdd, что при ребилде, что при линейной записи.
Сомнительная затея. На записи ничего не выигрываете всё равно. Лучше отдать больше памяти непосредственно мускулу и его кешам. Тем более если база занимает всего 1гб. Я бы смотрел в первую очередь в сторону оптимизации настроек мускула и пересмотру структуры базы.
+ tmpdir = указать на папку, которая в RAM.
Это даёт прирост,если временные таблицы mysql пытается кидать на диск. Причём прирост очень бывает ощутимым.
на самом деле скорость линейного чтения/записи на порядок выше.
И именно мелкие запросы от мускуля нереально долбят диски
А по поводу кеширования
как кешировать, например запрос в котором ставиться +1 при каждом открытии страницы и посещаемости даже в 2-3к уников в сутки?
Другое дело, если это каталог статей - где всё относительно статически или тот же самый варезник.
Лет 5 назад я держал корпоративную базу mysql на ram-диске, только причина была другой - тогда модны были внезапные налеты налоговых инспекций с выключением электропитания, чтоб менеджеры ничего не успели удалить с хардов :) ну и начальство переживало по этому поводу. Бекапы дампа базы делались где-то раз в час в инет, на "засекреченный сайт". Ну а скорость работы с базой была действительно почти фантастичной. Риски менеджеров - пропажа данных за последний час работы, фигня вообщем.
Привет,
может быть у кого-то был такой опыт или у меня параноя ;)
Вообщем поанализировал немного работу нескольких серверов и пришел к выводу, что основную нагрузку создаёт I/O и в большинстве случаев - это mysql.
SSD-диски не рассматриваете? Вот есть мечта сделать 10-ку на серверных SSD... 🤪