- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Мне нужно хранить в ОЗУ сервера большое количество страниц, около 60 тыс. Конкретно, две таблицы на 60 тыс и 8 тыс записей.
При чтении запросов из БД время ответа сервера 400-600 мс. При чтении из ОЗУ всего 60 мс. Поэтому хочу хранить таблицы в ОЗУ как можно дольше.
БД всего 100 Мб. ОЗУ на 2 Гб (VPS).
Как это можно решить? Каждый день вручную краулить сайт Screaming Frog-om не интересно, надо чтобы работало на автомате.
Добрый день.
Мне нужно хранить в ОЗУ сервера большое количество страниц, около 60 тыс. Конкретно, две таблицы на 60 тыс и 8 тыс записей.
При чтении запросов из БД время ответа сервера 400-600 мс. При чтении из ОЗУ всего 60 мс. Поэтому хочу хранить таблицы в ОЗУ как можно дольше.
БД всего 100 Мб. ОЗУ на 2 Гб (VPS).
Как это можно решить? Каждый день вручную краулить сайт Screaming Frog-om не интересно, надо чтобы работало на автомате.
Скорее всего в ваших таблицах не хватает индексов - рекомендую проставить.
А так есть тип memory перегоняйте данные туда и читайте с неё, ну или можно залить все в другие типы хранилищ, но вам помогут индексы
Скорее всего в ваших таблицах не хватает индексов - рекомендую проставить.
А так есть тип memory перегоняйте данные туда и читайте с неё, ну или можно залить все в другие типы хранилищ, но вам помогут индексы
Спасибо, подумаю над этим
Настройте сервер нормально, таблицы InnoDB автоматически полностью загружаются в БД при частом использовании данных.
Но если записи не будет, то тип таблиц MEMORY как выход. Но опять же там нужно настроить сервер, чтобы они туда помещались.
Так же мы не знаем что у вас за таблицы и что за запросы.
Подскажите, почему таблицы memory не оптимизируются? Как это исправить?
http://joxi.ru/zANYMpJFvopyG2
Забудьте про кнопку Оптимизация. НИКОГДА не пользуйтесь ей, если не знаете что это и как проходят там процессы.
Для Memory явно нечего оптимизировать.
Забудьте про кнопку Оптимизация. НИКОГДА не пользуйтесь ей, если не знаете что это и как проходят там процессы.
Для Memory явно ничего оптимизировать.
Даже так... А я где-то читал оптимизировать таблицы время-от времени полезно. Данные со временем фрагментируются, оптимизация удаляет всё лишнее и ускоряет работу таблицы...
Даже так... А я где-то читал оптимизировать таблицы время-от времени полезно. Данные со временем фрагментируются, оптимизация удаляет всё лишнее и ускоряет работу таблицы...
Не нужно "где-то читал" и сразу тыкать. Всё это уже в прошлом. При использовании InnoDB лучше вообще руками всё делать, чем нажимать "Оптимизировать" т.к. она просто блокирует таблицу и делает бэкап и в чистую заливает всё. Никаких чудес.
Но при этом сайте лежит и если не ДАЙ бог додумается кто-то mysql перезагрузить или весь сервер, могут случиться необратимые последствия.
Не нужно "где-то читал" и сразу тыкать. Всё это уже в прошлом. При использовании InnoDB лучше вообще руками всё делать, чем нажимать "Оптимизировать" т.к. она просто блокирует таблицу и делает бэкап и в чистую заливает всё. Никаких чудес.
Но при этом сайте лежит и если не ДАЙ бог додумается кто-то mysql перезагрузить или весь сервер, могут случиться необратимые последствия.
Спасибо, разберусь подробнее в этом