Homo-Adminus Blog

[lang_en]

So, I’s been a long time since I wrote my last post here. Lots of work and almost no new interesting technologies in my work caused such delay. But today I’m proud to announce release of really interesting project: MySQL Master-Master replication manager – set of flexible scripts for management different MySQL deployment schemes with master-master replication involved.

More information about this software could be found in detailed announce in Peter Zaitsev blog (actually this software was created by me for his company’s client) or at project page. All your questions and suggestions welcomed in MMM development group on Google Groups. If you’d like to support this software on Digg.com, you’re welcome.

[/lang_en]

[lang_ru]

Очень много времени прошло с момента моего последнего поста здесь. Много работы и практически полное отсутствие новых технологий в работе – вот основные причины. Ео сегодня я с удовольствием хочу аннонсировать здесь очень интересный проект: MySQL Master-Master replication manager – набор очень гибких скриптов для управления различными схемами установки MySQL, в которых используется master-master репликация.

Более детальная информация о проекте может быть найдена в детальном обзоре в блоге Петра Зайцева (на самом деле, программа создавалась мной для одного из его клиентов) или на странице проекта. Все вопросы и замечания можно отправлять в группу MMM development на Google Groups. Если вы хотите поддержать данный анонс на Digg.com, я буду не против.

[/lang_ru]

[lang_en]

I spent almost all day trying to find and fix really strange bug in one of our server-side applications written on Perl. And as I’ve figured out later, there is huge problem in Perl core libraries or, even, in interpreter.

Problem is following. If you are trying to use “threads” module with “Thread::Semaphore” module like it is mentioned in official Perl documentation (perlthrtut), you’ll get 4kb memory leak on every $semaphore->up call. So, simple test-case like following would cause huge memory leaks (100 Mbytes per second on my test server):
[/lang_en]

[lang_ru]

Я потратил сегодня почти весь день пытаясь найти и поправить очень странную ошибку в одном из наших серверных приложений, написанных на Perl. И, как выяснилось в процессе, в системных библиотеках Perl или, может быть, в его интерпретаторе, есть крайне неприятная ошибка.

Проблема в следующем. Если вы попытаетесь использовать модуль “threads” вместе с модулем “Thread::Semaphore”, как это описано в официальной документации по языку Perl (perlthrtut), вы получите утечку памяти размером около 4kb на каждый вызов $semaphore->up. Следовательно, следующий простой пример кода вызовет просто огромные утечки памяти (около 100 Mбайт в секунду на моем тестовом сервере):
[/lang_ru]

Read the rest of this entry →

[lang_en]

Looks like MySQL Camp 2006 was really interesting and useful for its attendees and for entire MySQL community. As the result of this meeting of many MySQL-related professionals we’ve got lots of interesting publications and I want to refer one of them in this post. Very interesting list of 84 MySQL performance tips has beed created on first day of this year MySQL Camp at Google headquarters:

1. Index stuff.
2. Don’t Index Everything
3. Use benchmarking
4. Minimize traffic by fetching only what you need.
   • Paging/chunked data retrieval to limit
   • Don’t use SELECT *
   • Be wary of lots of small quick queries if a longer query can be more efficient
5. Use EXPLAIN to profile the query execution plan
6. Use Slow Query Log (always have it on!)
7. Don’t use DISTINCT when you have or could use GROUP BY
8. Use proper data partitions (For Cluster. Start thinking about Cluster *before* you need them)
9. Insert performance
   • Batch INSERT and REPLACE
   • Use LOAD DATA instead of INSERT
10. LIMIT m,n may not be as fast as it sounds
11. …

So, I think this list can be really useful for all developers/DBAs working with MySQL and want to say “Thanks” to its authors.

[/lang_en]

[lang_ru]

Похоже, что MySQL Camp 2006 был действительно очень интересным и полезным событием как для тех, кто его посетил, так и для всего сообщества MySQL. Как результат этой встречи большого количества профессионалов, связанных с MySQL, появилось множество интересных публикаций. Именно одну из таких публикаций я и хотел бы “прорекламировать” сегодня. Очень интересный список 84 Лучших советов по производительности MySQL был создан в первый день работы MySQL Camp в штабквартире Google:

1. Index stuff.
2. Don’t Index Everything
3. Use benchmarking
4. Minimize traffic by fetching only what you need.
   • Paging/chunked data retrieval to limit
   • Don’t use SELECT *
   • Be wary of lots of small quick queries if a longer query can be more efficient
5. Use EXPLAIN to profile the query execution plan
6. Use Slow Query Log (always have it on!)
7. Don’t use DISTINCT when you have or could use GROUP BY
8. Use proper data partitions (For Cluster. Start thinking about Cluster *before* you need them)
9. Insert performance
   • Batch INSERT and REPLACE
   • Use LOAD DATA instead of INSERT
10. LIMIT m,n may not be as fast as it sounds
11. …

Я думаю, что этот список советов может быть очень полезен всем разработчикам и администраторам, работающим с MySQL и потому хочу сказать “Большое Спасибо” его авторам.

[/lang_ru]

[lang_en]

Sometimes you may need to implement controlled downloads when all downloads requests being sent to your script and then this script decides what to do: to send some file to the user or to show some access denied page or, maybe, do something else. In lighttpd server it can be done by returning X-Sendfile header from script. Nginx have its own implementation of such idea using X-Accel-Redirect header. In this short post I will try to describe how to use this feature from PHP and Rails applications.

[/lang_en]

[lang_ru]

Иногда вам может быть нужно реализовать т.н. контролируемое скачивание, когда все запросы на скачивание файлов передаются скрипту, который решает, как поступить: отправить пользователю какой-либо файл, или показать стриницу access denied, или, может быть, сделать что-то еще. При использовании сервера lighttpd это может быть реализовано при помощи заголовка X-Sendfile, возвращаемого из скрипта. Nginx имеет свою союственную реализацию описанной идеи с использованием заголовка X-Accel-Redirect. В этой короткой статье я попытаюсь описать, как использовать эту возможность из приложений на PHP или Rails.

[/lang_ru]

Read the rest of this entry →

[lang_en]

Sometimes we may need to know geocode of some specific postal location. For example, you have some shops catalogue and want to show shop locations on the map. Then, you will need to ask some service about map marker coordinates. If geocode service is not available or it can’t parse provided address, you will not be able to show map to your users. To solve such problem I’ve created small PHP-module, that helps me to get reliable results from set of miscellaneous geocoding services.

As for now, module can use Google Maps API, Yahoo Maps Services, Geocoder.us and Geocoder.ca services, but it is easily extensible and I can almost any services there. So, if you know some other services, that providing longitude/latitude pair by postal address, drop me a note and I will try to add its support to library.

[/lang_en]

[lang_ru]

Иногда нам бывает необходимо узнать геокод (geocode), соответствующий определенному почтовому адресу. Например, у Вас может быть каталог магазинов и вы хотите показывать расположение конкретных магазинов на карте. Стандартным решением является запрос к каким-либо geocoding-сервисам, которые выдадут вам широту и долготу указанного вами адреса для изображения маркеров на карте. Но, если geocode-сервис не доступен или не сможет разобрать предоставленный ему адрес, то вы не сможете показать пользователям карту. Для решения данной проблемы я написал небольшой модуль на PHP, который помогает мне получать надежные результаты в большинстве случаев просто используя несколько различных geocoding-сервисов.

На данный момент модуль умеет использовать Google Maps API, Yahoo Maps Services, Geocoder.us и Geocoder.ca, но он легко расширяем и потому я могу добавить туда практически любой другой источник данных. Поэтому, если вы знаете какие-либо сервисы, способные предоставить широту и долготу по указанному почтовому адресу, сообщите мне и я буду раз добавить поддержку этого сервиса в библиотеку.

[/lang_ru]