- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
А сколько у вас запросов в секунду?
Можно вынести базу на отдельный VPS. Используйте хорошего провайдера.
Для 10М строк не представляю зачем может понадобиться больше 4Gb RAM.
У меня на 2Gb RAM отлично работают около 40М.
Установите на VPS самый новый Ubuntu Server и руками(!), без всяких панелей, свежий Mysql.
Разверните дамп базы.
Удалите лишние индексы и не пишите в конфиг лишние настройки.
Поставьте для начала только innodb_buffer_pool_size=3G
Проведите тесты скорости.
Если все будет ОК, либо:
- настройте репликацию и читайте со второго сервера в режиме slave, либо
- полностью переключайте коннект к базе на него.
Весь поиск нужно по возможности вынести в Sphinx или Elastic.
У вас есть возможность показать схему основной таблицы, со всеми индексами?
Я про это:
CREATE TABLE `post` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`title` varchar(250) NOT NULL DEFAULT '',
`keywords` varchar(2048) NOT NULL,
`slug` varchar(250) NOT NULL DEFAULT '',
`quote` varchar(2048) NOT NULL DEFAULT '',
`content` text NOT NULL,
`time_int` int(11) unsigned NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `slug` (`slug`),
KEY `time_int` (`time_int`)
) ENGINE=InnoDB AUTO_INCREMENT=11021 DEFAULT CHARSET=utf8mb4;
Возможно, нужно денормализовать или наоборот нормализовать таблицы.
Очевидно, что нужно индексы правильные прописывать, т.к. если запрос выполняется несколько секунд, то индексы скорее всего не используются или используются частично.
Настройками сервера или более мощным железом такое не победить. Только переделывать таблицы.
Настройками сервера или более мощным железом такое не победить. Только переделывать таблицы.
С этим согласен. Кроме редких случаев, когда настройки ну очень уж кривые :kozak:
И править базу лучше не на production сервере.
Поэтому дроплет на DO и можно начинать эксперименты.
хороший, опытный разработчик окупится на долгой дистанции.
такой сервер, с виду избыточен. тем более вечные зависания
БД у вас маленькая
Сколько вредных советов:)
Запихните проблемные данные SphinxsSearch или ElasticSearch и всё небудет проблем:)
kxk, обрати внимание на исходные данные, база всего 3 гб, всего 10 млн строк. Это вообще ниочем, и запросы по id должны в миллионных количествах выполняться моментом даже на вдс с гигом оперативки, на DO такой вдс стоит 10$
И не нужно тут никаких highload решений.
Проблема тут или с совсем убитых дисках или в адово кривой архитектуре базы без индексов.
foxi, Зачем спорить проще сделать и не иметь проблем:)
А тем временем я чет не наблюдаю схемы БД, тупящих запросов и их explain. :)
Отписавшимся проблема интересней, чем ТС. :)
Может у ТС-а сервер БД за океаном или на Луне? :)
Вопрос можно решить элементарно, взять VPS c SSD под такую БД, развернуть БД там, подключить с такого тестового сервера и посмотреть, повлияет ли это на скорость.
Если это все на HDD, удивительно, что это занимает только 3 секунды.
Вопрос можно решить элементарно, взять VPS c SSD под такую БД, развернуть БД там, подключить с такого тестового сервера и посмотреть, повлияет ли это на скорость.
Если это все на HDD, удивительно, что это занимает только 3 секунды.
Ага, а раньше, когда не было SSD, запросы выполнялись по пол дня:)
Как можно судить о производительности БД (не видя запрос) только по описанию железа?
ТС скорее всего либо забил на вопрос либо уже решил:)