>хорошо не буду. Вы НЕ ПОКАЗАЛИ . что Вы сделали - и
>это не облегчило процесс поиска источника/устранения ошибки. так нормально? Может быть и так. Но что я должен был показать? давать конкретные линки на статьи в инете, которые перечитал, но которые мне показались не подходят? будет список на пол страницы, если не более.
>ели Вы на даты постов внимание обратите, то станет ясно что ВЫ
>перечитали тему, которую я указал, но решение проблемы все же искать
>не захотели. как и в той теме кстати ). банально -
>не захотели читать доки с mysql.org - ибо их там
>много.
Не вижу никакой связи. Еще раз объясняю: я заметил проблему, начал гуглить, почти первой темой была та, на которую Вы давали ссылку (а так же несколько примерно в том же ключе на буржуйских сайтах); и еще раз повторяю - не пытался применять те советы, потому как лог мускуля (да, по моей ошибке) был пустой (и не надо про доки с mysql.org, именно прочитав там, что лог включается кроме параметра комм. строки еще и системной переменной log-warnings=1 я и попытался включить его через my.cnf). Перепроверил когда Вы наехали на меня.
Документацию с mysql.org я читал (именно в этом ведь был Ваш совет в той теме), да, там указываются 4 переменных, отвечающих за тайм-ауты, как возможная причина аборта коннекта, и, как я уже писал, кручение этих переменных результата не дало. Кроме того, как написано в статье по тюнингу пробовал уменьшать размеры буферов - тоже видимого результата не дало. Может я что-то не допонял, но разве не для этого просят помощи на форумах?
>>Предложенный в той теме вариант с кручением таймаутов и буферов - не
>>дал результата; помогло использование proxymap:
>потенциальная дыра, даже при использовании "подвинутого" на безопасности постфикса.
А можно поподробнее? кроме того, что в манах написано "not trusted daemon and should not be used to lookup sensetive data etc". гугль тоже в основном ссылку на ман дает.
