maxcom

Традиционно радует статистика броузеров на linux.org.ru:

1) Firefox - 39.93%
2) Opera - 28.82%
3) IE - 9.98%
4) Chrome - 9.61%
5) Mozilla - 4.36% - не совсем понятно, подозреваю что это надо прибавить к ff
6) Safari - 2.8%

гм, видимо скоро состоится победа Chrome над IE

Попробовал использовать довольно интересную фичу нового PostgreSQL - btee_gin. Это расширение, позволяющее засоввывать в поисковый индекс дополнительные поля, например дату, число или boolean (полный список поддерживаемых типов по ссылке).

Без этого расширения поиск по тексту с учетом дополнительных критериев всегда включает в себя полную выборку по текстовому запросу, которая затем так или иначе фильтруется по дополнительным критериям. С btree_gin можно сразу получить из индекса то что нужно, что (потенциально) быстрее.

Вторая полезная фича поиска - gin_fuzzy_search_limit, она появилась еще в 8.2 (или в 8.3). Этот режим позволяет ограничить выборку по индексу для запросов, которые выдают слишком много ответов, поскольку такие запросы исполняются долго и сильно грузят БД (особенно если потом хочется их всех отранжировать и отсортировать). Фактически это режим "выдачи глупых ответов на глупые запросы". Это значение не должно быть слишком маленьким, нужен еще некоторый запас на фильтрацию по нетекстовым критериям. gin_fuzzy_search_limit задает примерное максимальное число ответов, которое мы хотим получить.

Эксперимент по использованию gin_fuzzy_search_limit совместно с btee_gin по тексту и дате оказался не удачным. Для примера рассмотрим индекс по тексту и дате, и искать будем сообщения за последний год. Тестировалось два запроса - первый по слову "linux". При поиске без даты в индексе за год мы получали ~3000 ответов (gin_fuzzy_search_limit = 10000, остальное отфильтроввывавалось по дате). При поиске по индексу с датой - 130 ответов. Хуже ситуация с редковстречающимся словом, например, 'gravatar' (оно еще хорошо тем, что встречается только в этом году). Это слово встречается всего 33 раза, так что при отсутствии даты в индексе из поиска мы получаем все 33 ответа. При наличии даты в индексе - слово не находится вообще, или находится в 1-2 документах (как повезет).

Насколько я понимаю, в данном случае gin_fuzzy_search_limit ограничил отдельно выборку по дате (фактически выбрар произвольные 10000 сообщений этого года) и отдельно выборку по слову, а затем сделал им 'join', выкинув значительную часть полезных результатов.

Имхо данная проблема сильно ограничивает применимость btree_gin в реальной жизни, по крайней мере в вебе.

Как-то так: http://drf-ckoff.livejournal.com/229508.html

PS: Сергей, рисуй еще plz :-)

Тюнил полнотекстовый поиск по lor (пока еще не затюнил до конца). PostgreSQL умная база, ее разуму можно доверять. Однако иногда вылезает жуткая тупизна оптимизатора, которую приходится обходить бесчеловечными извратами. Надо будет попробовать 8.4

Хочу поделиться одним довольно интересным deadlock'ом, на который я уже дважды наступил на linux.org.ru.

Предыстория такова. Для доступа к БД мы используем пул соединений, ограниченого размера. Пул устроен таким образом, что при недоступности запрос встает в очередь в ожидании свободного соединения.

Скрипты, генерирующие страничку обычно где-то в начале получают Connection, потом в конце его отдают. В новый скриптах это делается в контроллерах, в старом бардаке - прямо в коде JSP (но там мы используем большие буфера чтобы предотвратить Slow Lori атаки на соединения БД). Код работы с БД довольно запутан и размазан по исходникам.

В первый раз deadlock выглядет так - редко, наверное пару раз в месяц сайт полностью умирал. Все запросы висели в ожидании соединения к БД, все активные соединения висели в idle, БД и система были совершенно не загружены. Классическая картина "утечки" соединений, однако код был многократно исследован на эту тему - вся работа с БД была обернута в try { ... } finally, в котором соединение закрывалось. Никаких статических буферов для соединений к БД у нас нет. Принудительный вызов сборки мусора ситуацию не лечил.

Второй раз deadlock проявлялся сильнее, поскольку ошибка была сделана в скрипте генерирующем главную страницу - сайт после deploy'я жил несколько минут, после чего лочился.

Собственно причина лока была успешно установлена еще в первый раз, предлагаю читателям самостоятельно догадаться о причине (в github не смотреть :-)

Единственное уточню:

1) Пулы соединений предоставляет сервер приложений (tomcat), они работают корректно
2) Действительно вся работа с БД обернута в try { .. } finally, все что получается из пула туда обратно возвращается по окончанию скрипта
3) Все учавствующие в дедлоке запросы к БД работают довольно быстро, "перенагрузки" системы, БД и ввода вывода нет. Однако скорость возникновения лока напрямую зависит от популярности страницы, на которой сделана ошибка
4) Deadlock возникал не в следствии каких-то DoS или других "вредоностных" действий пользователей

:-)

(thanx to transient@habr)

Кстати Yandex зачем-то удалил linux.org.ru из поисковой выдачи. Мелочь, а неприятно. И не понятно с чего бы вдруг

После шаманских плясок вокруг адаптера удаленного доступа удалось запустить KVM. Сайт ожил, внешних повреждений нет.

Т.к. DNS открутили на сервер с страницей о ошибке то сайт будет доступен как только все обновится обратно.

Однако пока что уверенности что все будет жить далее стабильно нет.

После выключения сервера по питанию на час машину удалось в каком-то виде загрузить, по крайней мере теперь она выводит какую-то информацию о загрузке BIOS на подключенный монитор и пытается грузить ядро, но не успешно. К сожалению, встроенный KVM ничего не передает.

Завтра утром поеду в серверную, буду разбираться.

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

На l.o.r какая-то аппаратная проблема, разбираемся.

Кстати да, http://www.linux.org.ru/view-message.jsp?msgid=3187835

IE 5/5.5/6 под Linux: http://www.tatanka.com.br/ies4linux/page/Main_Page. Поставилось за 1 минуту, даже работает. Теперь анонимусам которые жалуются на плохой вид linux.org.ru под эксплорером настанет счастье.

Жаль IE7 пока нет.

http://www.linux.org.ru/jump-message.jsp?msgid=2216910

http://drf-ckoff.livejournal.com/135552.html

Сделал поисковик на базе tsearch2 с GIN-индексами для linux.org.ru. Ищет довольно шустро, поиск занимает до 20 секунд на базе в 2 млн сообщений. Редко встречающиеся слова ищет вообще мгновенно, видимо много времени уходит на сортировку по релевантности при поиске с большим количеством попаданий.

Но первичное индексирование в целом заняло часов 5.

Провел несколько экспериментов по прикручиванию memcached к linux.org.ru. Вполне себе прикручивается и работает, надо будет, видимо заменить кеширование веб-акселератором от resin целиком на memcached. Ибо из-за кеша резина приходится кодировать логин пользователя в URL, да и к тому же в новой версии resin кеш убрали (он доступен теперь только в платной редакции). Thanx to mds за наводку.

Поставил недавно счетчик google analytics на www.linux.org.ru. Помимо всего прочего с интересом поглядел на статистику броузеров.

Забавно, но сейчас на первом месте Firefox (38%), на втором Opera (26%) и лишь на третьем IE (23%). Раньше помнится эксплорер лидировал с сильным отрывом от остальных. Если включить в статистику операционки, то под виндой IE и Firefox идут практически рядом (23% у IE и 21% у Firefox).

Хорошо.

Решил понемного выводить движек linux.org.ru из каменного века. Поставил Subversion и Trac.

Про subversion писать не буду, скажу что после CVS мне он очень нравится.

Trac более интересная игрушка. Интегрированный пакет состоящий из bugtracker'а, wiki и броузера SVN. Удобный и функциональный интерфейс, ставится легко (хотя и требует компиляции какого-то невходящего в дистрибутив Fedora питоновского модуля).

Новое (для меня) слово в вебсайтостроении: http://en.wikipedia.org/wiki/Cross-site_request_forgery

И еще одна серия из истории починки винта на l.o.r:

( Read more... )