Мда? Вот потому, что ты такой бред пишешь, тебя и отправляют учить мат часть.
Ты это имеешь в виду?
Цитата:
Страничный кэш в системе Linux ("Cached:" в meminfo) является в большинстве систем самым крупным потребителем памяти. Каждый раз, когда вы выполняете операцию чтения read () из файла, расположенного на диске, данные считываются в память и помещаются в страничный кэш....
Squirrel пишет:
Да нифига подобного. Данные останутся в КЭШе, читай в памяти, и только в случае длительного простая, и при условии нехватки памяти другим задачам, твои данные будут удалены из кэша физически.
В дисковом кеше останутся? Я имел ввиду кеш MySQL.
Цитата:
Кроме результатов, MySQL хранит в кеше список таблиц, выборка из которых закеширована. Если в любой из таблиц, выборка из которой есть в кеше, проиcходят изменения (вставка или изменение строк), то MySQL удаляет из кеша такие выборки. Такой подход ускоряет работу MySQL, но может быть неэффективным для систем с большим количеством запросов на изменение таблиц.
Я не отрицаю того что есть то чего я не знаю.
Но я сравнил один и тот же запрос к таблице типа MyISAM и MEMORY без использование кеширования MySQL. С таблицы типа MEMORY выборка была сделана в два раза быстрее. Проходов было сделано 2000 на каждый тип таблицы.
Я понял что данные с файла будут помещены в дисковый кеш и если к ним будет частое обращение то они там будут долго. Наверно это связано с самим механизмом работы с таблицами MyISAM и MEMORY.
потому и надо.
Сервер БД сам закеширует в памяти часто используемые данные.
Я не очень корректно написал название темы, но описание корректное.
Я с вами согласен но вы не до конца поняли именно эту задачу.
MySQL кеширует данные. Но если таблица была изменена то данные уже не будут браться с кеша а опять сделают выборку с диска.
Таблица состоит из строк в котором один столбец типа INT(4). (если использовать MYSQL).
Выборка почти никогда не попадет в кеш так как данные часто изменяются, по этой причине даже отключено кеширование данного MySQL запроса.
По этому нужно хранилище к которому есть быстрый доступ но запросы к нему не будут помещены в кеш а данные удалены пока сервер не будет перезагружен или не будет произведен запрос на удаление.
Берут конкретный скрипт и нагружают бенчмарками выходя из предполагаемой нагрузки.
Потом выбирают подходящий сервер чтобы в запасе было около 25% мощности.
caballero
Мемкеш я не могу использовать потому что он не дает гарантии сохранения данных. В то время как MySQL будет их хранить до перезагрузки сервера или удаления запросами. Мелкий,
Спасибо.
Я не гуру в администрировании и не знал что "хорошие" сервера своп не используют (хотя у себя на 3 серверах я ни разу не видел использования свопа). Но думал что это штатная ситуация.
О том что данные после рестарта пропадут мне известно.
Но в данный момент меня это не сильно беспокоит (Сервер MySQL работает 88 дней, 11 часов, 0 минут и 19 секунд.).
Я сравнил операцию вставки в таблицу MyISAM и операцию выборки. Вставка была равна 8Е-5 в то время как выборки с этой же таблицы 0.025460679789652 (это MyISAM).
По этому я решил так - данные одновременно будут записываться в две таблицы. На диск и в память.
В случае рестарта сервера запуск MYSQL будет происходить через скрипт который сначала запустит MySQL а потом скопирует в MEMORY таблицу данные с той таблицы которая на диске.
Как я понял. Сервер не должен использовать СВОП. И если он это сделает то просто нужно добавить памяти. То есть я могу не переживать о том что данные MySQL попадут в файл подкачки.
Вы никак не можете хранить данные в некотором хранилище (в данном случае - ОЗУ), если их размер превосходит размер хранилища.
Это понятно. Но выше я привел размер таблицы со 100 000 тысячами записей в MYSQL. Их размер по сравнению с общим количеством ОЗУ очень мал.
Опишу как я понял работу memcached: выделено место (например 250мб) и кеш их будет занимать потихоньку, со временем когда кеш будет заполнен он начнет удалять старые данные.
Мне было бы удобно выделить 20Мб памяти под таблицу и чтобы они все время были зарезервированы для нее. Благо 20 Мб памяти это совсем не много. Но чтобы ни при каких обстоятельствах они не попали в СВОП. Или все равно, если для других процессов не будет хватать памяти то они этот контейнер размером 20Мб вытеснят в СВОП? Хотя он активно используется (данные с контейнера).
Здравствуйте,
Стоит задача проверки IP пользователя на уникальность за текущие сутки. Самый простым способом есть хранение данных в таблицы MySQL и выборка данных с нее. Но нашел я такой тип таблиц как MEMORY таблицы. И это было то что мне нужно. Таблицу я сделал самой простой, один столбец в котором был IP преобразованный при помощи INET_ATON().
Скорость проверки наличия адреса в этой таблице была ровно в два раза больше чем в аналогичной таблице при использовании MyISAM. А размер со 100 000 тысячами записей всего 2мб. И все казалось хорошо, но была прочитана мной одна особенность. Данные могут попасть в СВОП что в данном случае сыграет против меня.
Думал попробовать хранить данные при помощи memcached но там тоже оказались минусы. В случае нехватки выделенной памяти старые данные будут удалены что никак не позволительно в данной ситуации так как список IP мне нужен за последние 24 часа. Есть ли какой то способ сделать так чтобы данные гарантировано находились в ОЗУ и к ним был быстрый доступ но в тоже время они никуда не пропадали в случае если память закончилась. (можно выделить для memcached много памяти, но это все равно не гарантирует сохранность данных).
Или может у меня не правильный подход к этому?
Попробовал вариант от пользователя LIME - заработало так как нужно.
Вариант от пользователя Мелкий - тоже работает как нужно.
Подозреваю что в функции explode() тоже идет проверка внутри при помощи регулярных выражений.
Пустые строки убирают обе функции. Я подумал сначала что второй вариант лучше но проверил и убедился что и в первом пустые строки убраны.
Но вот определение:
Цитата:
PHP_EOL (string)
Корректный символ конца строки, используемый на данной платформе. Доступна начиная с версии PHP 4.3.10 и PHP 5.0.2
То есть если пользователь отправляет форму с ОС где символы переноса строки не такие как на сервере то будет ошибка такая же как я описал. Еще проверю, но кажется что будет ошибка если данная константа не такая как символ(ы) переноса строки на машине клиента.
Пока вам спасибо устное. Наберу достаточное количество сообщений и отблагодарю.
При дебаге с применением var_dump() получаю длины значений массива: 13,13,13,12 . Визуально все одинаковое. Не понятно почему длина значений разная. Там есть какой то еще скрытый символ? Я думал что если перенос обозначен \n то он заменен. Хотя читал что может быть еще и \r вместе с \n. Получается что проблема в скрытом \r ?
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 17
