|
Задавайте вопросы, мы ответим
Вы не зашли.
Здравствуйте. Подскажите пожалуйста мне по нескольким воросам.
1. Много читал про постоянные соединения, что они уменьшают нагрузку на сервак и т.п. У меня такая ситуация: чуть более 100 форумов на одной базе (5.0.22, MyISAM) на выделенном сервере. Как то пробовал включить pconnect, получилось что постоянно висело 70+ процессов, но ведь по идее должен быть один? Собственно интересует почему их так много, ведь эти форумы используют одни и теже файлы, один и тотже логин-пасс к БД, только таблицы в БД разделены для каждого форума префиксами.
2. Внешние ключи позволяют связать столбцы разных таблиц. А возможно ли сделать так, чтобы значение одного столбца равнялось сумме 2х других в одной таблице и автоматически изменялось с изменением двух первых?
c1 c2 c3(c1+c2)
-------------
32 5 37
24 22 46
57 3 60
3. Какие ключи помогают сортировкам?
Неактивен
1. Одного соединения, конечно, не будет - у Вас же несколько человек _одновременно_ обращаются
к базе => одновременно несколько постоянных соединений открыто. Другое дело, что когда один сценарий
отработал, другие потом могут использовать уже установленное свободное соединение.
2. Это можно сделать с помощью триггеров.
3. Сортировкам помогают правильные ключи 
Все зависит от запроса. Допустим, для запроса
"SELECT ... FROM a WHERE b = 1 ORDER BY c" правильным ключом будет ключ на (b,c).
Неактивен
1. Интересно Но в таком случае наверно лучше увеличить max connections. Если увеличить max connections ничег больше ненужно изменять?
2. Думаю в моём случае так нужно?
Неактивен
Мммм... одно плохо - триггер не может изменять ту же таблицу. Иначе будет рекурсия.
Но в данном случае можно немного схитрить 
можете посмотреть еще в сторону количества открытыхНеактивен
Спасибо большое. Сразу и про кодировку спрошу. В бд стоит латина, как то задумал сделать конвертацию, почитал мануальчики, но не стал этог делать т.к. бд весит около 3 гигов, комп просто не откроет такой большой дамп))) Так вот... я потом задумался, а стоит ли вообще замарачиваться с этой кодировкой? Ведь всё нормльно работает, русский текст выводится, с буквой "ё" вроде проблем не замечал. Конечно не удобно в phpmyadmin как отображается текст, и это пока единственная несущественная проблема для меня. И всё таки как будет лучше, оставить латину или переделать на cp1251 ? Влияет кодировка как то на производительность?
Неактивен
"Работает - не трогай"
А вообще - если будут какие-то проблемы - то восстанавливать будет куда сложнее. latin1 - семибитная
кодировка. При попытке запихать туда данные из любой другой кодировки - русские буквы не пролезут.
Т.е. если Вы тупо сделаете dump / restore - данные не восстановятся (т.к. дамп в utf8).
Реально Вам нужно менять только метаданные. Насколько я понимаю, у Вас единственная база в этом
экземпляре MySQL, поэтому самое простое - поставить кодировку по-умолчанию cp1251 для сервера
(default-character-set = cp1251) и перезапустить сервер. Тогда таблички от четверки подхватятся сразу
в нужной кодировке. Если таблички уже сконвертированы в формат пятерки - то увы, прийдется преобразовывать
так, как написано в статье.
Неактивен
В логах выскакивает такая ошибка:
090120 01:10:09 mysqld restarted
... /bin/mysqld: Out of memory (Needed 714548224 bytes)
и строк "Out of memory" несколько подряд.
А иногда бывает такая:
[ERROR] Out of memory... длинющий текст с разъяснениями на английском, затем список переменных key_buffer_size,... и формула результат которой равен 1809630К
Все эти ошибки указывают что у меня завышенные параметры конфига?
Оперативки 2 гига.
Конфиг:
key buffer size 768M
sort buffer size 4M
read buffer size 1M
table cache 1,024
Отредактированно EzheG (20.01.2009 10:13:32)
Неактивен
Наверное, еще и 32-битная операционка. На 32-битной платформе процесс не может выделить
более 2 гигабайт ОЗУ, (даже если есть своп в Вашем случае) - прийдется уменьшить параметры.
Ну или обновить ОС
Неактивен
Понятненька...
А вот эти значения что показывают?
Key_buffer_fraction_% 72.31 %
Key_write_ratio_% 67.25 %
Key_read_ratio_% 0.68 %
Как я понимаю table_cache задаёт память для хранения инфы о таблицах... а сколько отводится памяти для одной таблицы? Ну хотя бы примерно
А то у меня вот как ))))
Open_tables 1,024
Opened_tables 74 k
Неактивен
Эти значения показывают заполненность буффера и соотношение запрос/реальных действий
для записи и чтения ключей. Это написано в мане той утилиты, которую Вы тут не написали
Примерно на хранение дескриптора таблицы выделяется 4 байта внутри программы + сколько-то
байт внутри libc... думаю, порядка нескольких десятков.
Неактивен
paulus, спасибо Вам большое
Стал разбираться в одном тормозном запросе
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE f ALL PRIMARY,id NULL NULL NULL 60 Using temporary; Using filesort
1 SIMPLE t ref PRIMARY,forum_id forum_id 2 f.id 11
1 SIMPLE p ref topic_id,forum_id topic_id 4 t.tid 280 Using where
И к тому же в таблице forums почему то разрабы сделали двойной ключ на id:
Неактивен
Самже нашёл ошибку в запросе, нужно вместо "AND p.forum_id NOT IN (3, 27)" сделать "AND f.id NOT IN (3, 27)".
Но двойной ключ всё равно непонятен мне.
Неактивен
Второй такой же ключ, конечно же, не нужен
Неактивен
Здравствуйте. Читал статейки про внешние ключи и появилось пару вопросов.
В настоящее время в MyISAM работают внешние ключи? А то читал что они работают только в InnoDB только. Ещё где то читал что они могут вроде как работать в MyISAM но при создании таблицы если в коде прописан внешний ключ то он не обрабатывается. Сейчас же поставил внешний ключ на 2 таблицы своей БД и был приятно удивлён что определённые запросы используют его. Поставил второй ключ на другие таблицы - никакого эффекта в explain'е. В phpmyadmin нет вывода внешних ключей. И при создании дампа внешние ключи там не проявляются. Чорт знает что кароче Может их и не использовать? )))
Неактивен
В MyISAM внешние ключи не работают - при создании таблицы вместо них создаются обычные ключи.
Неактивен
До недавних пор всё работало хорошо, но вдруг посыпались ошибки:
[ERROR] /usr/.../mysqld: Can't find file './dbserv/table_groups.frm' (errno: 23)
[ERROR] Error in accept: Too many open files in system
Проводил проверку и починку таблиц, надеялся что этим решится первая ошибка. Но ничего. Сайт, кстати, несмотря на эту ошибку работает нормально. Но из-за второй бывают частые перебои, при заходе на сайт пишется 403 ошибка О_о
Очень странно. Подскажите как решить проблемы?
Неактивен
VDS? Вы упираетесь в количество открытых дескрипторов в системе. Нужно поднять этот параметр.
Если крутить эту ручку не можете, можно попробовать ограничить количество открытых таблиц
(open_tables_limit) и соединений с базой (max_connections). Но это приведет, возможно, к другим
проблемам типа «не хватает соединений»...
Неактивен
Выделенный серв.
max connections 300 стоит, но в реале не превышает 80.
table cache 5,092
tmp table size 33,554,432
max heap table size 33,554,432
max tmp tables 32
open files limit 11,095
До этого open files limit был ровно в 3 раза больше table cache и всё работало нормально, но вдруг стало тупить. Подскажите, есть ли логика в моих настройках с учётом того в бд тысячи таблиц?
Отредактированно EzheG (13.05.2009 22:33:04)
Неактивен
Логика open_files_limit = 3*table_cache_size очень даже оправдана
(1 MyISAM табличка = frm + MYD + MYI).
Неактивен
Спасибо. Попробую уменьшить эти оба параметра.
Подскажите пожалуйста по такому ещё вопросу. Действительно ли советуется использовать NOT NULL везде, где только можно?
Неактивен
NOT NULL нужно использовать там, где предполагается, что значение обязательно, т.е.
во всех случаях, кроме того, когда Вы уверены, что колонка должна быть NULL
Неактивен
