В первую очередь я обратил внимание на те параметры, которые отображаются красным в PhpMyAdmin, и на которые обращает внимание tuning-primer.sh.

tuning-primer.sh — хороший скрипт, анализирует логи и параметры MySQL и даёт советы по оптимизации, мне он понравился больше чем mysqltuner.pl

Для установки выполняем:

wget http://day32.com/MySQL/tuning-primer.sh
chmod 755 tuning-primer.sh

Потом запускаем:

./tuning-primer.sh

Большое значение Created_tmp_disk_tables

В процессе работы MySQL для каждого соединения постоянно создаются временные таблицы, большое значение Created_tmp_disk_tables (у меня было 45% от общего числа создаваемых) означает, что временные таблицы создаются не в памяти, а в временных файлах на диске, что замедляет работу MySQL. За выделение памяти для временных таблиц отвечают параметры tmp_table_size и max_heap_table_size в конфиге. Я увеличивал значения этих параметров, но количество создаваемых таблиц на диске не уменьшилось.

Проблема оказалось была вот в чём: если в таблицах используются поля типов TEXT (TEXT, TINYTEXT, MEDIUMTEXT …) или BLOB, то таблица не может быть размещена в памяти, а только на диске. Эти типы полей могут содержать в каждом поле большой объём текста или данных, и в MySQL данные физически не хранятся в самой таблице, а в поле содержится ссылка на сами данные.

Раньше для текстовых данных с длиной поля больше 255 символов альтернативы особой не было, всегда приходилось использовать поле типа TEXT. Но, начиная с версии 5.0.3 тип поля VARCHAR может хранить в себе 65535 байт (до этого только 255 байт). Для всех видов SQL операций, работа с полем VARCHAR происходит быстрее, чем с полями типа *TEXT, но самое главное, что временные таблицы с полями VARCHAR хранятся в памяти.

После того, как я сконвертировал все поля типов TEXT в VARCHAR, значение created_time_disc_tables уменьшилось, и теперь таблицы создаваемые на диске составляют 8% от общего количества, т.е. улучшение в 5 с половиной раз.

Правда, тут есть небольшое ограничение. Одна строка данных (сумма размеров всех полей) в MySQL таблице не может быть больше 65535 байт, т.е. нельзя создать в таблице два поля VARCHAR размером 65000 байт, например. Можно создать два поля размером 32767 байта, или одно поле 32767 и два по 16388.

Кэш запросов и высокое значение Qcache_lowmem_prunes

Кэш запросов может неплохо помочь в случае слабо оптимизированных скриптов, когда часто выполняются одни и те же выборки SELECT. Если запрос уже находится в кэше, то MySQL не обращается к таблицам, а берёт его прямо из кэша, что очень быстро (т.к. кэш в памяти). У меня в моих базах данных из кэша берутся 90% всех запросов.

Qcache_lowmem_prunes — показывает количество запросов которые были удалены из кэша из-за нехватки памяти. Если не хватает размера кэша, то MySQL оставляет в памяти только самые популярные запросы, а редкие из него удаляет. Чтобы уменьшить большое количество Qcache_lowmem_prunes я сначала пытался постепенно увеличивать размер кэша запросов, доведя его до 768 мегабайт. Это не помогло, Qcache_lowmem_prunes не уменьшилось, процент эффективности кеша также не вырос.

Затем я более подробно изучил, как работает кэш, и поменял тактику. Дело в том, что если таблица меняется (происходит INSERT, DELETE или UPDATE), то все запросы из кэша для этой таблицы удаляются. Если кэш большого размера, то на его обслуживание нужно тоже время (т.к. память не может быть освобождена моментально). Часто обновляемые таблицы, по сути, только замедляют работу с кэшем, т.к. запросы почти сразу же удаляются и только фрагментируют кэш.

Для всех таблиц которые часто обновляются, я прописал директиву SQL_NO_CACHE (например SELECT SQL_NO_CACHE * FROM table), принудительно ограничивающую кэширование. Также для больших таблиц, везде где возможно, я прописал названия выбираемых полей в SELECT (например SELECT SQL_NO_CACHE id,name FROM table), что уменьшило размер возвращаемых данных, и увеличило количество запросов, которые могут поместиться в кэше. Несмотря на то, что сейчас размер кеша 256 Мб, количество Qcache_lowmem_prunes резко уменьшилось.

Борьба с Table_locks_waited и перевод некоторых таблиц на InnoDB

Table_locks_waited — показывает количество событий, когда запрос на блокировку таблиц был выполнен через определенный период ожидания. MyISAM — основной движок таблиц в MySQL имеет один большой недостаток, когда происходит изменение таблицы (кроме INSERT в конец таблицы), то она блокируется на чтение, а когда происходит чтение из таблицы, то она блокируется на запись. Другими словами запросы SELECT и UPDATE, DELETE, INSERT не могут проходить одновременно, и когда они пытаются делать это одновременно, какому то запросу приходиться ожидать и возникает Table_locks_waited событие.

Для небольших таблиц блокировка занимает доли секунды и практически не заметна, но ситуация меняется, если в таблице сотни тысяч или миллионы записей. Каждое обновление занимает заметное время, и в случае большой нагрузки происходит лавинообразный рост блокировок, в логе медленных запросов появляется много безобидных SELECT’ов, выполняющихся по несколько секунд, хотя обычно они выполняются за тысячные доли секунды, а некоторые страницы сайтов начинают медленно отдаваться.

Самое обидное, что эти ситуации сложно отследить при создании сайта, я столкнулся с этим через полтора года после того как некоторые таблицы выросли до миллиона записей. Решений этой проблемы несколько.

Первый способ, кардинальный, переделать логику работы с базой данной так, чтобы она обновлялась как можно реже, либо выборки SELECT шли из одной таблицы, а обновления INSERT, UPDATE, DELETE в другую, и например, раз в сутки они синхронизировались.

Второй способ, для таблиц MyISAM есть неплохое решение (если в таблицу происходят только частые вставки INSERT) использовать оператор DELAYED (Например INSERT DELAYED INTO table VALUES (…) ). При таких вставках они не выполняются в данный момент времени, а вставляются отложено с низким приоритетом, т.е. MySQL ждёт пока выполнятся все SELECT запросы и таблица освободится для записи. Такая вставка происходит реже, MySQL собирает сразу несколько таких запросов и вставляет их все вместе, что снижает нагрузку. Большой минус — для очень загруженных таблиц, запрос вставки может вообще никогда не произойти (если таблица не освободится), также в случае падения MySQL сервера все ожидающие запросы пропадут.

По моему опыту, даже не на очень загруженных таблицах данные могут вставлены только через несколько минут (запросы которые ожидают, или долго выполняются можно видеть в реальном режиме времени с помощью утилиты mytop). Из-за своих недостатков, DELAYED подойдет только для не очень важных данных, которые сразу не нужны, и которые не так страшно потерять, например логи.

Третий способ, перевести такие таблицы на InnoDB — более продвинутый движок для таблиц, который поддерживает транзакции, но самое главное, блокировка в InnoDB работает не на уровне всей таблицы, а на уровне отдельных строк. Т.е. могут происходить одновременные запросы на запись и чтение в таблице.

Плюсы InnoDB:

• Поддержка транзакций (если не нужны, то не является плюсом)
• Меньше вероятность потерять данные при падении сервера (только если используются бинарные логи)
• Блокировки на уровне строки (а не всей таблицы, как для MyISAM)
• Выдерживает большую нагрузку при больших размерах таблиц
• Показывает большую производительность при одновременных запросах на чтение и запись

Минусы InnoDB:

• Индексы в 2-3 раза большего размера, чем для MyISAM
• Нельзя восстановить таблицу из файла (без бинарного лога), нужно регулярно делать бэкапы, чтобы не потерять данные
• Для быстрой работы InnoDB нужно существенно больше оперативной памяти (переменная innodb_buffer_pool_size)
• Точное количество элементов в таблице, в определённый момент времени можно узнать только примерно (запросы COUNT (*) для всей таблицы очень медленно выполняются)
• Время выполнения вставки/обновления больше чем для таблиц MyISAM.

InnoDB или MyISAM это тема для большого холивара, в интернете я так и не нашёл единого мнения что лучше, у кого то серьёзные аргументы за MyISAM, у кого то за InnoDB .  Эти движки таблиц имееют свои различия, плюсы и минусы, и выбор больше зависит от архитектуры построенной базы данных. Для себя я вывел правило: если таблица редко обновляется, то лучше использовать MyISAM, если таблица имеет большой размер и часто обновляется, то лучше использовать InnoDB. Конечно, блокировки случаются и в InnoDB — но для моих данных это случается на несколько порядков реже, а если и случаются то время блокировки незначительное (несколько миллисекунд).

Для быстрой работы InnoDB самое главное это размер буфера innodb_buffer_pool_size, т.к. InnoDB сильно кеширует индексы и данные в памяти. Размер памяти для этой переменной зависит от размера таблиц, я у себя выделил 1 гигабайт памяти (у меня InnoDB таблицы вместе с индексами занимают 600-700 мегабайт).

Для максимально быстрой работы InnoDB устанавливаем innodb_flush_logs_at_trx_commit  равным нулю. Если переменная равна нулю, то логи сохраняются не после каждой транзакции, что уменьшает надёжность, но даёт самую быструю скорость. Если  innodb_flush_logs_at_trx_commit = 1, то логи сохраняются после каждой транзакции, что крайне медленно, если значение равно двум — то раз в 1-2 секунды.

После месяца исследований и тестов, удалось решить все проблемы с базой данных, всё забегало очень шустро, пропали почти все медленные запросы. Ещё раз убедился в поговорке “век живи, век учись”.

Тим Бёртон как всегда жгёт. Даже очень как то жизнерадостно для него. А Джонни Деппа раскрасили в роль шляпника так, что даже не узнать. Красивый фильм. Нужно ещё на 3D сходить.

Кэмерон опять порвал всех. Насколько помню себя, все его фильмы чем то по-настоящему удивляли и шокировали. От первого терминатора мне стало плохо прямо в кинотеатре (смотрел в лет десять). Второй терминатор смотрел в 92 году за рубль в пионерском лагере в подпольном видеосалоне, была набитая комнатка людей и маленький телевизор, тогда это было для детского сознания просто шок, настолько фильм казался реальным. Чужие, до сих пор считаю его самым страшным блокбастером. Титаник, за билетами к которому вместо пары в лицее стояли почти два часа. Ещё Бездна, Правдивая ложь. Вот теперь и новое откровение — Аватар. Кэмерон, наверное продал душу дьяволу =)

Хотел посмотреть именно в 3D, поэтому пришлось ждать, когда откроют первый в Минске 3D кинотеатр “Киев”. Билеты на полтора месяца вперёд расхватали в течении одной недели. Уверен, если бы кинотеатр принадлежал не государственной конторе, а частнику, то сеансов было бы не два-три в сутки, а ещё утром и поздней ночью (заработали бы лишние $100k+). Что радует, Аватар дал настолько сильный толчок развитию 3D кино в мире, что 3D кинотеатров, фильмов станет больше. Уже почти приняли стандарт 3D для Blu-ray что позволит смотреть трёхмерное кино дома (хотя понадобиться 120 Гц телевизор).

В 3D, конечно, погружение в фильм максимальное. Очки уже не просто с сине-красными стёклышками, а с спектральными фильтрами, т.е. изображение полноцветное, только менее яркое (все цвета показываются на экране), хотя у технологии Digital 3D есть определённые недостатки. Во-первых слегка уменьшают эффект рамки экрана. Во-вторых в реальном мире мы неосознанно фокусируемся на нужном нам объекте, а в 3D нужно подстраиваться под фокус камеры, иначе изображение размывается, особенно это чувствуется в очень динамичных сценах. Впрочем ко всему этому быстро привыкаешь в процессе просмотра. Особенно, в Аватаре удались всякие мониторы и интерфейсы будущего, внутри них изображение тоже трёхмерное! =).

Кстати расскажу один секрет, как увидеть любое изображение или обычный фильм (не 3D)  — по-настоящему трёхмерным. Вычитал из книжки Перельмана “Занимательная Физика” ещё в детстве. Всё очень просто, нужно сесть поближе и просто… посмотреть одним глазом! Если смотреть одним глазом, то наш мозг не получит никакой информации о объёме, наше зрение будет двухмерное, и мы увидим ровно ту трёхмерную проекцию которую запечатлел “одноглазый” объектив фотоаппарата или кинокамеры. Т.е. всю информацию о трёхмерности наш мозг получит из картинки (по теням и положению объектов) и изображение станет по настоящему трёхмерным! Правда смотреть одним глазом кино совсем неудобно и непривычно т.к. поле зрения уменьшится почти в два раза, но объёмность картинки на какое то время ощутить удастся.

http://soft.compulenta.ru/507427/

“В первом квартале прошлого года вредоносные PDF-файлы фиксировались в 56% случаях всех эксплойтов, отслеживаемых ScanSafe. Этот показатель вырос до 60% во втором квартале и до 70% в третьем. Последняя четверть года показала 80-процентную популярность Acrobat-взломов из всех ПО-атак.”

Так что, самым лучшим советом для понижения уязвимости системы будет совет не ставить антивирусы и файрволы, а не устанавливать Adobe Reader вообще. Я когда перешёл на Win 7, установил альтернативу — Foxit Reader, делает то же что и Adobe Reader, но быстрее работает и меньше памяти жрёт.

Особенно меня бесят эти сокращённые ссылки, по которым не видно на какой сайт переходишь. Всё это напоминает мне маленьких детей, вот для них то наверное и предназначен твиттер: “я покушал кашку”, “ух ты, какую?”, “вкусную”, “а я сходила на горшок”, “а сегодня мама купила мне машшшинку..”, “а у меня, а у меня.. а у меня вот что есть!”. Единственное на что годится твиттер (и ему подобные) так это для анонсов (но это по сути дублирует RSS) и как чат в реальном режиме времени для подростков.

Я провожу в интернете по 8 часов в день, у меня в Google Reader около полусотни интереснейших блогов и RSS лент, но я не успеваю нормально прочитать и трети из них. Я не могу воспринимать эти ленты, хотя каждый день достаточно много читаю. Наверное я уже слишком старый, или наоборот ещё не повзрослел… =)

Качать тут: http://www.commandandconquer.com/classic

Эх были времена. Command & Conquer вышел в 95 году и шокировал своей графикой, игровым процессом, музыкой. Помню, запускался даже на компьютере с 386 процессором (играл у друга, у меня компьютер гораздо позже появился). Вот Westwood умела делать раньше стратегии. До сих пор интересно иногда переигрывать. Не то что сейчас.

Источник: http://soft.compulenta.ru/503554/

Видимо Microsoft решила задушить своё детище собственными руками. По-моему мнению Windows Mobile (у меня на HTC Diamond стоит версия 6.1) с оболочкой от HTC (заменяющей все основные приложения на свои) не так плоха. Просто юзабилити у этой ОС нужно доработать как следует (в том числе и для управления пальцами).

Кстати, насчёт даты спутниковой съемки Минска в Google Maps и Яндекс Картах я угадал. В Google Maps Минск за 11 августа 2009, а в Яндексе за 22 апреля. Те и те снимки есть в Google Earth. Самые ранние снимки Минска есть за 2001 год.