А как ещё можно можно объяснить РЕАЛЬНУЮ ситуация, которая повторяется 10 раз подрят?
работает база в 2х режимах.
1. Все летает, тоесть база переваривает в секунду 2000 обращений к ней (кол-во записей 10млн. размер 1ГБ) при кол-ве фрагментов <100, при этом поиск по ней точного вхождения длится 0,0003 сек
2. Все тормазит, тоесть база переваривает в секунду 200 обращений к ней (кол-во записей 10млн. размер 1ГБ) при кол-ве фрагментов >500, при этом поиск по ней точного вхождения длится 0,05-0,15 сек.
И все решается дефрагментированием.
Оптимизация как-то не правильно срабатывает - тоесть БД задумывается - файлы БД таскает, но в итоге фрагментированность остается и устраняется тольк WIN дефрагментатором
PS.
Заливка БД в RAM оказалась только временной примочкой, при достижение фрагментированности БД 5000 фрагментов - производительность ниже плинтуса (аналогично что на жестком диске при кол-ве фрагментов >500)
PPS.
Кто что ище может посоветовать?
(Может можно какнибудь искуственно раздуть БД чтобы она использовала выделенное её пространство, аля создание разреженного файла?)
На всякий случай сообщаю структуру БД
int(11) | varchar(80) | int(11)
первичный ключ | индекс | индекса нет
Сильная фрагментация - >500 кусков файла.
Пробовал, но почемуто нужного эффекта не достигается - фрагментированность остается, наверное умная ОС пишет файл как её кажется более правильно, а не чтоб занять свободное место.
Вот за это спасибо!
Незнал о такой возможности.
Единственная проблема, с которой сталкнулся - установил RAMDisk "Enterprise", а он как оказалось создает диски которые ни ОС ни др. программы не воспринимают как полноценные диски.
Но выручил SuperSpeed RamDisk.
Всем спасибо!
Тоже идея (оставить на главном диске первую запись а остальное утянуть на доп. диск), но харды "справляются" (RAID загружает ЦП по полной) как появляется сильная дефрагментация (а она появляется через 10 минут работы) - производительность резко снижается (надеюсь от этого спасет вынос на отдельный диск - никакие другие процессы на пути файлов БД чтоб ничего не писали).
А что будет с индексами? - они тоже растянутся по дискам пропорционально? или останутся на исходном?
Народ совсем ни юмора не понимает, ни смотреть внимательно не хочет.
Там счетчик стоит, отображающий статистику от pochta-ru http://www.liveinternet.ru/click;pochta-ru
☝ Вы на счетчик посматрите ☝
Сразу поймете что цена занижена:)
Он в нижнем левом углу. От LI, а от майла наверное глючит :) .
База используется не для коммерческого применения, а для личного опыта, а т.к. раньше с мюскулем работал - вот с помощью него и решил объщитать (раньше максимальные базы с которыми работал ограничивались 50тыс. записями - так что граблей никаких не встречал)
такчто жду подсказки.
Самое тупое решение которое видится - поставить для этой БД отдельный MySQL сервачек, который будет крутиться на доп. HDD и на отличном порту от основного сервера, но решение кажется не очень красивым.
прикольно, только косячок не большой
А вывод только на мобилку. Да и скорее всего если спалят что куча выводов на 1н номер, то тоже не оплатят.
Конешно по запросам.
(т.к. абонентка всеравно повлечет за сабой ограничение по кол-ву запросов, а многим не нужно каждый день мониторьть тонны запросов)
С 1го IP в сутки 1к запросов.
купив у хостера ещё 1н IP имеем ещё 1к запросов в сутки, а т.к. IPки мы покупаем на 30 дней, то получается что 1 IP за $3 дает нам 30к запросов в месяц.
куда уж дешевле чем 150р?
только выделенный IP 90р ($3)
