Меню
Что нового?

Потоки MYSQL безбожно жрут память

betik

Новичок
Потоки MYSQL безбожно жрут память

Собственно сабж. Каждое открытое соединение с MySQL отжирает 12 Мб оперативки...
RH Linux 7.x3
MySQL 3.23
Apache 1.23 (или в этом духе)
PHP 4.3.4
Zend optimizer

Можно ли как-нть настроить чтобы потоки жрали поменьше? Скрипты работают долго, больше чем минута... 30 запросов в минуту практически убивает сервер..... Уничтожить соединение - не предаставляется возможным из скрипта до того времени, как скрипт не закончит свою работу....
При этом есть 3Гб места под своп, но максимум в своп попадает 10 Мб...
Оперативы 512...
Проц П4... в районе 1400-1700...
 
confguru

confguru

ExAdmin
Команда форума
pconnect ?
Медленные запросы отслеживаешь?
explain запросов делал?
 

betik

Новичок
...Нет, не Pconnect
Запросы меньше чем за 0.01 сек выполняются.
Explain делал, все индексы нужные на месте...
Да и не в них дело... Скрипт сначала считывает информацию из базы, а потом посылает данные в сокет и ждёт ответа... Таймаута у create_socket нет. Удалённый сервер может и не ответить или долго отвечать - канал нестабильный... И тогда всё повисает =(...
В принципе перед отправкой можно закрыть соединение... Но после успешной/неуспешной отправки в сокет скрипт пишет статистику в БД. Прийдётся открывать опять соединение. Но на сервере установлен лимит на одновременно открываемые соединения в 15 штук. Снять ограничение - возможности нет.
Поставить цикл, который будет долбиться в мускул пока не соединится - имхо будет ещё больше грузить. Оставить без соотв. записи о результате - тоже нельзя никак.
Писать в текстовый файл а потом в БД - финансирования нет.
 
tony2001

tony2001

TeaM PHPClub
>MySQL 3.23
уже можно обновить, 3.23 уже устарела.

>RH Linux 7.x3
впрочем, как и RH 7.x уже ушел в прошлое.

>PHP 4.3.4
а это вообще смешно.
 

betik

Новичок
Tony... Никто туда не будет ставить новую ось. Соответственно и работает там стабильно только Mysql 3.23 и PHP 4.3.4 . Мускул вообще не собирается 4-й, ядро не нравится, а PHP больше чем 4.3.4 неправильно работают с массивами... И наверно не только с ними, но массивы - точно.

2админ - соединение с мускул в это время не закрыто, мускул висит в процессах....

ЗЫ дак как же настройть так, чтобы один процесс mysql'я не мог есть больше опр. кол-ва памяти???
 
tony2001

tony2001

TeaM PHPClub
>Tony... Никто туда не будет ставить новую ось. Соответственно и работает там
>стабильно только Mysql 3.23 и PHP 4.3.4 .

если бы работало стабильно, ты бы, наверное, не спрашивал, да?

>Мускул вообще не собирается 4-й, ядро не нравится,

стабильно, да.

>а PHP больше чем 4.3.4 неправильно работают с массивами...

м-да.

>И наверно не только с ними, но массивы - точно.

больше ничего не происходит?
в подвале нет стука? предметы обихода сами по себе не летают?
 

betik

Новичок
Нет, больше ничего не летает/падает/стучит.
Всё ок. Только процесс МуСКУЛа жрёт 12 МБ оперативки. А я хочу чтобы жрал, например, 5 Мб.
 
tony2001

tony2001

TeaM PHPClub
>После получения данных надо закрывать соединение.
ерунда.
оно закрывается автоматически.
 
confguru

confguru

ExAdmin
Команда форума
betik
tony2001

Значит нужно это дело кешировать и натравливать
парсер - который бы и работал с сокетами.

P.S. Имхо это или просчеты архитектуры или ненадежная техника (ака каналы)
 

betik

Новичок
Тони... Вникни в алгоритм:

1. Соединяемся с БД (получаем 12 мб откушеной памяти)
2. Получаем данные из БД.
3. Работаем с сокетом (очень долго, не исключён вариант что это будет вечно).
4. Записываем результат в БД.
5. die(); (конец скрипта)
6. Получаем назад 12 Мб памяти.

Если сделать после 2 пункта mysql_close то сразу получим назад 12 Мб и в общем-то проблема с памятью решится. Но! Тогда после третьего пункта нужно будет вписать mysql_connect. Не факт, что соединение установится с первого раза - лимит на одновременные соединения жесток. Делать while? А если сто раз подряд стучать к мускулу без остановки сколько процессорного времени сожрёт скрипт?... Плохо тоже... Единственный выход, которыя я вижу - на уровне настроек демонов запретить отдавать больше n мб памяти любому мускульному процессу... Либо делать фальшивых киллеров...

-~{}~ 03.07.05 22:13:

admin, это как в сказке про Балду... Подешевле да получше...
 
slach

slach

Новичок
IMHO криво собран mysql (в смысле слишком много памяти в настройках выставлено)

можно поглядеть my.cnf ???
а также результаты SHOW VARIABLES ???
 

betik

Новичок
slach, в my.cnf ничего относительно ресурсов нету.. Собирал не я, пересобрать мне не дадут. 99% что собирался он так:

./configure
make
make install

....

SHOW VARIABLES счаз покажу:

back_log 50
basedir /usr/
binlog_cache_size 32768
character_set latin1
character_sets latin1 dec8 dos german1 hp8 koi8_ru latin2 swe7 us...
concurrent_insert ON
connect_timeout 5
datadir /var/lib/mysql/
delay_key_write ON
delayed_insert_limit 100
delayed_insert_timeout 300
delayed_queue_size 1000
flush OFF
flush_time 0
have_bdb NO
have_gemini NO
have_innodb NO
have_isam YES
have_raid NO
have_openssl NO
init_file
interactive_timeout 28800
join_buffer_size 131072
key_buffer_size 8388600
language /var/lib/mysql/mysql/english/
large_files_support ON
locked_in_memory OFF
log OFF
log_update OFF
log_bin OFF
log_slave_updates OFF
log_long_queries OFF
long_query_time 10
low_priority_updates OFF
lower_case_table_names 0
max_allowed_packet 1048576
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connections 100
max_connect_errors 10
max_delayed_threads 20
max_heap_table_size 16777216
max_join_size 4294967295
max_sort_length 1024
max_user_connections 0
max_tmp_tables 32
max_write_lock_count 4294967295
myisam_max_extra_sort_file_size 256
myisam_max_sort_file_size 2047
myisam_recover_options 0
myisam_sort_buffer_size 8388608
net_buffer_length 16384
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
open_files_limit 0
pid_file /var/run/mysqld/mysqld.pid
port 3306
protocol_version 10
record_buffer 131072
record_rnd_buffer 131072
query_buffer_size 0
safe_show_database OFF
server_id 0
slave_net_timeout 3600
skip_locking ON
skip_networking OFF
skip_show_database OFF
slow_launch_time 2
socket /var/lib/mysql/mysql.sock
sort_buffer 2097144
sql_mode 0
table_cache 64
table_type MYISAM
thread_cache_size 0
thread_stack 65536
transaction_isolation READ-COMMITTED
timezone EDT
tmp_table_size 33554432
tmpdir /tmp/
version 3.23.56
wait_timeout 28800
 
confguru

confguru

ExAdmin
Команда форума
Не факт, что соединение установится с первого раза - лимит на одновременные соединения жесток
Нажмите для раскрытия...
Какой лимит? У тебя хостинг за 5$ чтоли?

Я уже предложил разделить этот процесс...
При таком раскладе получается слегка асинхронный,
но работающий процесс...
1 - фетчер
2 - сокет демон
3 - бд упдатер
 
AnToXa

AnToXa

prodigy-одаренный ребенок
гхм, а откуда вы вообще себе придумали про 12M я непойму.
ну стека у него по дефолту 2M, да и то из них используется не так много.

остальное - все кэши и буфферы там общие для всех потоков.
и 12M весь сервер баз данных - вообще нисколько.

было бы там 12G, был бы разговор.
 
tony2001

tony2001

TeaM PHPClub
AnToXa
есть подозрение, что это у него на старом редхате так показываются потоки - как отдельные процессы.
а то, что эти потоки юзают те же либы и др. ресурсы, старый top не понимает.
 
AnToXa

AnToXa

prodigy-одаренный ребенок
tony2001
да мне и новый топ точно также все показывает :)
просто я знаю что такое потоки :)
 
tony2001

tony2001

TeaM PHPClub
у меня вне зависимости от кол-ва соединений всегда 2 процесса в ps.
 
AnToXa

AnToXa

prodigy-одаренный ребенок
tony2001
то ли в сусе такой уродский топ(что более вероятно), но помнится на RH можно было включать threads view.
у мя счас оно просто по дефолту всегда включено.

через ps можно посмотреть все точно.
 
Войдите или зарегистрируйтесь для ответа.
Сверху