powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Срочно нужна помощь с оптимизацией INNODB
71 сообщений из 71, показаны все 3 страниц
Срочно нужна помощь с оптимизацией INNODB
    #38838505
kayuchkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Друзья, добрый день!
Помогите, пжлста, не можем понять в чём дело.

Есть INNODB-база, размером 6Gb.
На сервере практически ничего, кроме базы нет. Размер оперативной памяти -- 16Gb.
Всё работало нормально, с недавних пор база начала жутко тормозить и вешать сервер, примерно вот так:

Код: powershell
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
last pid: 16384;  load averages: 78.58, 77.64, 76.12                                                                                                                                up 2+18:35:12  21:39:50
60 processes:  4 running, 56 sleeping
CPU: 99.1% user,  0.0% nice,  0.9% system,  0.0% interrupt,  0.0% idle
Mem: 5086M Active, 7529M Inact, 2018M Wired, 1876M Buf, 1146M Free
Swap: 4096M Total, 4096M Free

  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 9476 mysql       117  22    0  9427M  5304M RUN     1  67.4H 151.12% mysqld
 1940 www           1  20    0   290M 44172K accept  0   1:25  0.49% httpd
15522 www           1  42    0   290M 38540K accept  1   1:37  0.00% httpd
15543 www           1  35    0   290M 44996K accept  0   1:33  0.00% httpd
…



Вот что показывает mytop:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
MySQL on localhost (5.5.38-log)                                                                                                                                                     up 1+13:48:17 [21:46:12]
 Queries: 44.9M  qps:  346 Slow:    3.1k         Se/In/Up/De(%):    60/00/19/00 

 Cache Hits: 3.5M  Hits/s: 26.6 Hits now:   0.0  Ratio: 12.9% Ratio now:  0.0% 
 Key Efficiency: 100.0%  Bps in/out: 68.5k/138.0k   

    Id      User         Host/IP         DB      Time    Cmd Query or State                                                                                                                                 
    --      ----         -------         --      ----    --- ----------                                                                                                                                     
...



В топе самые разные запросы, время выполнения везде нулевое.

Вот my.cnf:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
[mysqld]
datadir=/var/db/mysql
socket=/tmp/mysql.sock
max_connections=100
innodb_buffer_pool_size=8G
innodb_use_sys_malloc=0
innodb_file_per_table=1

max_heap_table_size=128M
innodb_flush_log_at_trx_commit = 0

wait_timeout = 5
interactive_timeout =   30

log-slow-queries = /var/log/mysqld/mysql-slow.log
long_query_time = 5
key_buffer_size = 16M
query_cache_size = 128M
query_cache_limit = 32M
table_cache = 500
thread_cache_size=4
sort_buffer_size = 16M
myisam_sort_buffer_size = 16M
join_buffer_size = 16M
ft_min_word_len = 2
tmp_table_size = 128M
max_tmp_tables = 64
tmpdir = /tmp/mysqltemp

[client]
default-character-set=cp1251

[mysql.server]
user=mysql
basedir=/var/db/mysql



Mysqltuner показывает вот что:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
[OK] Currently running supported MySQL version 5.5.38-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +CSV +InnoDB +MRG_MYISAM 
[--] Data in InnoDB tables: 2G (Tables: 64)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 17

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 1d 13h 55m 1s (47M q [346.190 qps], 280K conn, TX: 19B, RX: 9B)
[--] Reads / Writes: 72% / 28%
[--] Total buffers: 8.3G global + 32.6M per thread (100 max threads)
[OK] Maximum possible memory usage: 11.5G (72% of installed RAM)
[OK] Slow queries: 0% (3K/47M)
[!!] Highest connection usage: 100%  (101/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/95.0K
[OK] Key buffer hit rate: 100.0% (257M cached / 16 reads)
[!!] Query cache efficiency: 12.9% (3M cached / 28M selects)
[!!] Query cache prunes per day: 4107
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 332K sorts)
[!!] Temporary tables created on disk: 48% (246K on disk / 510K total)
[OK] Thread cache hit rate: 97% (8K created / 280K connections)
[!!] Table cache hit rate: 3% (500 open / 14K opened)
[OK] Open file limit used: 0% (1/11K)
[OK] Table locks acquired immediately: 99% (75M immediate / 75M locks)
[!!] Connections aborted: 6%
[OK] InnoDB buffer pool / data size: 8.0G/2.2G
[OK] InnoDB log waits: 0



И вот ещё статус mysql:

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
mysql> show global status like '%qcache%';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| Qcache_free_blocks      | 651       |
| Qcache_free_memory      | 116680592 |
| Qcache_hits             | 3637010   |
| Qcache_inserts          | 16896324  |
| Qcache_lowmem_prunes    | 6490      |
| Qcache_not_cached       | 7627513   |
| Qcache_queries_in_cache | 3252      |
| Qcache_total_blocks     | 7409      |
+-------------------------+-----------+

mysql> show global status like '%open%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| Com_ha_open              | 0      |
| Com_show_open_tables     | 0      |
| Open_files               | 49     |
| Open_streams             | 0      |
| Open_table_definitions   | 105    |
| Open_tables              | 500    |
| Opened_files             | 988862 |
| Opened_table_definitions | 213    |
| Opened_tables            | 14348  |
| Slave_open_temp_tables   | 0      |
+--------------------------+--------+

mysql> show global variables like '%cache%';
+------------------------------+----------------------+
| Variable_name                | Value                |
+------------------------------+----------------------+
| binlog_cache_size            | 32768                |
| binlog_stmt_cache_size       | 32768                |
| have_query_cache             | YES                  |
| key_cache_age_threshold      | 300                  |
| key_cache_block_size         | 1024                 |
| key_cache_division_limit     | 100                  |
| max_binlog_cache_size        | 18446744073709547520 |
| max_binlog_stmt_cache_size   | 18446744073709547520 |
| metadata_locks_cache_size    | 1024                 |
| query_cache_limit            | 33554432             |
| query_cache_min_res_unit     | 4096                 |
| query_cache_size             | 134217728            |
| query_cache_type             | ON                   |
| query_cache_wlock_invalidate | OFF                  |
| stored_program_cache         | 256                  |
| table_definition_cache       | 400                  |
| table_open_cache             | 500                  |
| thread_cache_size            | 4                    |
+------------------------------+----------------------+
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838506
kayuchkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Готовы заплатить за оперативное решение проблемы.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838522
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
во временном каталоге (обычно /tmp) что происходит?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838524
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Что попадает в mysql-slow.log ?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838527
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kayuchkin
Код: sql
1.
[!!] Temporary tables created on disk: 48% (246K on disk / 510K total)

Основная проблема мне видится здесь.
Что-то произошло, и временные таблицы стали сваливаться на диск.
Вспоминайте, что менялось непосредственно перед тем, как возникла проблема.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838544
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kayuchkinГотовы заплатить за оперативное решение проблемы.

ds, хоть емейл открыли
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838546
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftkayuchkin
Код: sql
1.
[!!] Temporary tables created on disk: 48% (246K on disk / 510K total)

Основная проблема мне видится здесь.
Что-то произошло, и временные таблицы стали сваливаться на диск.
Вспоминайте, что менялось непосредственно перед тем, как возникла проблема.

на моё имхо вряд ли.
автор Highest connection usage: 100% (101/100)

я тупо за ддос.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838567
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторHighest connection usage: 100% (101/100)На мой взгляд это следствие того, что "Temporary tables created on disk: 48%". (пока отрабатывает один запрос, успевают набежать еще несколько).
По крайней мере, не наоборот.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838613
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kayuchkin,

1. По первой картинке явственно следует что сервак тупо не справляется с нагрузкой. Особых проблем с IO операциями ФС - явно нет.

2. СВОП файл от ОС - не используется, что говорит о достатке оперативы.

3. По тюнеру:
а) он прямо утверждает, что нехватает threads.
б) недостаточен кеш определений таблиц.
в) при избыточном буфере для иннодебилового кеша (8G при используемых 2.2G)
г) недостаточно оперативы для временных таблиц. 48% записи на диск - это многа.

Ну и из настроек бросается в глаза очень небольшой Join-buffer... не из-за этого создаются "времянки на диске"?

Ну и похоже, что дисковая подсистема сервера - явно слабовата. У вас в основном чтение. Поставьте нормальные серверные винты, хотя бы 2шт в raid1 и получите скорость чтения ФС от 240метров в секунду, вместо 60-80.

Возможно проблема в ДДОС, или его имитации. Тупо сервер не держит столько коннекций по другим местам и каждый запрос требует много мелких обращений к Мускулю ... кстати, там случаем Мускуль не настроен ДНС-ы искать?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838635
kayuchkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Коллеги, спасибо!
Если кто-то готов взяться за решение проблемы с оплатой за результат -- пишите на kayuchkin@gmail.com
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838760
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В джентльменский набор вопрошающего нужно еще включить pt-summary или даже pt-mysql-summary.
Он хотя бы приблизительное представление об конфигурации железа дает.

А тут особо халявы нет. Никто еще не смог парой параметров серьезно ускорить mysql. Ну разве что innodb_flush_log_at_trx_commit, но там уже 0.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838762
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А хотя тут еще freebsd. Не уверен даже что скрипт для этой умирающей экзотики правильно выдаст конфигурацию оборудования.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838849
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftkayuchkin
Код: sql
1.
[!!] Temporary tables created on disk: 48% (246K on disk / 510K total)

Основная проблема мне видится здесь.
Что-то произошло, и временные таблицы стали сваливаться на диск.
Вспоминайте, что менялось непосредственно перед тем, как возникла проблема.

А это ?
Код: sql
1.
[!!] Highest connection usage: 100%  (101/100)



не волнует ?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838850
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivА это ?
Код: sql
1.
[!!] Highest connection usage: 100%  (101/100)




не волнует ?я уже отвечал на это - 17026534
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838853
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftMasterZivА это ?
Код: sql
1.
[!!] Highest connection usage: 100%  (101/100)




не волнует ?я уже отвечал на это - 17026534

У них проблема скорее всего в

авторПомогите, пжлста, не можем понять в чём дело .

У них затык вообще в приложении, а они думают, что БД виновата.

ТС,
1) включите slow query log. Гуглите прямо так "mysql slow query log".
2) Увеличте максимальное число коннекций к БД. Процентов на 50 для начала.
Тут http://dev.mysql.com/doc/refman/5.5/en/too-many-connections.html сказано как.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838854
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivУ них затык вообще в приложении, а они думают, что БД виновата.в БД тоже не все гладко, как минимум.
По 2 временных файла на диске каждую секунду в среднем - это все-таки не мало. Если они хотя бы по сотне-другой мегабайт, то могут полностью утилизировать пропускную способность дисковой подсистемы.MasterZiv1) включите slow query log. Гуглите прямо так "mysql slow query log".Он включен. Вопрос о содержимом лога был. Ответа не было.
MasterZiv2) Увеличте максимальное число коннекций к БД. Процентов на 50 для начала.А смысл? ну встанут еще 50 сессий в очередь за ресурсами, которых нет, а толку-то?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838945
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,

Да, тоже сколоняюсь к моменту о времянках. Там получается на каждый запрос к серверу-клиента (PHP?) создается примерно по 2 времянки, из которых 1 - похоже лезет на диск "всяко".

Ещё смушает 17 фрагментированных таблиц...

Да, slow log очень бы было полезно глянуть.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38838950
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109Там получается на каждый запрос к серверу-клиента (PHP?) создается примерно по 2 времянкиА выделенное откуда следует?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839010
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,

Up for: 1d 13h 55m 1s (47M q [346.190 qps], 280K conn
и
Temporary tables created on disk: 48% (246K on disk / 510K total )


примерно 1 к 2. Не? :)
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839032
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ребята, надо искать конкретику.
"сервер тормозит" - это не проблема.
надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839033
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivребята, надо искать конкретику.
"сервер тормозит" - это не проблема.
надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо.

сразу видно с вебом вы не сталкивались.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839034
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowMasterZivребята, надо искать конкретику.
"сервер тормозит" - это не проблема.
надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо.

сразу видно с вебом вы не сталкивались.

да абсолютно все равно, web там или что.
бд запросы выполняет.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839037
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowMasterZivребята, надо искать конкретику.
"сервер тормозит" - это не проблема.
надо брать самый тормозящий запрос и тюнить. потом брать следующий и тюнить. и так до тех пор, пока все не будет работать хорошо.

сразу видно с вебом вы не сталкивались.
А в "моем" вебе эта техника нормально работает. Да и чего бы ей не работать, если люди думают и ошибаются примерно одинаково ?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839148
kayuchkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Коллеги, добрый день!
большое спасибо за ваши ответы и советы!
По поводу "брать каждый запрос и тюнить":
Мы давно и достаточно долго оптимизировали структуру базы и запросы, проверяли что везде используются нужные индексы и т.д.
Более того, этот проект ( http://puzzleit.ru) существует уже несколько лет, до этого он крутился на одном сервере при посещаемости около 200-300 просмотров страниц в сутки, сервер справлялся вообще без напрягов, проблем не было.
Недавно перенесли базы на отдельный сервер (он у нас пустовал -- такой же конфигурации, в этом же дата-центре, только оперативной памяти вдвое больше). После этого начались проблемы с базой. Очевидно, что проблема где-то в неправильной настройке базы или сервера, а не в неоптимизированных запросах.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839157
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Дополню по результатам просмотра на серверах:

1. С фряхой последний раз общался году в 93-м, поэтому нифига не помню где там и что ... не судить строго.

2. На обоих серверах стоит Мускуль, slow log есть и там и там, но с разным размером и датой:

На "основном серваке puzzleit.ru - он большой 366.7М от 21.12 03:10, а на серваке с БД - "маленький" 1.4М от 21.12 20:22.
Пока шарился - размеры файлов не менялись. Времена - тоже.

Или на серверах не настроено единое время ... или это разные БД. Где лежат файлы настройки Мускуля и файлы реплики, если таковая есть - не нашел.

В обоих логах есть запросы с левыми джойнами к 3 табличкам и с временем выполнения от 6.8 до 29 сек. При этом Мускуль просматривает от 1 до 4 миллионов записей с итогом выдачи от пусто до 5000... из характера запросов - не обнаружил необходимость именно левого соединения... но там похоже или какая-то cms или фреймворк.

Возможно левое соединение генерится автоматически. Это уже к автору.

Можно предположить, что ПХП-клиент с одного сервера обращается к БД на другой ... или нет?

В общем, кто лучше знает free bsd unix, тому и карты. :)
Не разобравшись с конфигурацией, смотреть саму БД не вижу смысла. Похоже, что косяк именно промеж серверов.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839159
kayuchkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Arhat109Можно предположить, что ПХП-клиент с одного сервера обращается к БД на другой ... или нет?


да, на самом деле сейчас происходит именно так, а это плохо? )

p.s.: сервера вроде как стоят рядом, в одном дата-центре
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839160
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kayuchkin,

ответил письмом. :)
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839189
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot kayuchkin]
По поводу "брать каждый запрос и тюнить":
Мы давно и достаточно долго оптимизировали структуру базы и запросы, проверяли что везде используются нужные индексы и т.д.
[/quot kayuchkin]
Почему-то многие считают, что внезапно в mysql ничего не происходит. Еще как происходит.
Время идет - данные накапливаются. Планы запросов изменяются. Индексы перестают использоваться. Буферов перестает хватать.
Это нужно делать постоянно. Ну хотя бы при заметных ухудшениях.

По-прежнему не видим конфигурацию. Хотя например NUMA, которая включается или выключается в зависимости от размера и способа установки памяти по слотам (ну тут уж точно тут во freebsd облажались. кто тестировать-то будет на разнообразном железе ?), может привести к аномальному замедлению работы простых запросов.
Все же CPU: 99.1% user больше намекает на необходимость оптимизации запросов.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839190
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kayuchkin,

срочно расстреляйте вашего верстальщика!!!
главная страница почти под 5 мегабайт, при том, что даже статика отдается еле-еле - за гранью.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839227
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kayuchkinНедавно перенесли базы на отдельный сервер (он у нас пустовал -- такой же конфигурации, в этом же дата-центре, только оперативной памяти вдвое больше). После этого начались проблемы с базой. Очевидно, что проблема где-то в неправильной настройке базы или сервера, а не в неоптимизированных запросах.

во первых, вовсе и не очевидно.
во вторых ты будешь когда разбирать первый запрос, ты и поймешь, что не так.

конфигурации "было" и "стало" сравнивали, надеюсь?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839228
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
интересно, мы содержимое mysql-slow.log увидим или нет?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839229
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kayuchkinArhat109Можно предположить, что ПХП-клиент с одного сервера обращается к БД на другой ... или нет?


да, на самом деле сейчас происходит именно так, а это плохо? )

p.s.: сервера вроде как стоят рядом, в одном дата-центре

нет, это наоборот хорошо.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839230
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кроме того, вы же данные т. н. Бэкапом переносили, наверное? Статистику по таблицам собирали после загрузки данных?
индексы все создали?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839241
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZivkayuchkinпропущено...


да, на самом деле сейчас происходит именно так, а это плохо? )

p.s.: сервера вроде как стоят рядом, в одном дата-центре

нет, это наоборот хорошо.
но плохо что их вообще разделили. ну, по крайней мере, это есть привнесенное изменение в систему из-за которого она может работать медленее.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839279
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,

Я его выкачивать не стал, не увидел в нем ничего такого, кроме регулярных запросов с большим временем выполнения, и они все идут с левым джойном к 3 и более таблицам. Главная - разная, вторая всегда users, третья и т.д. - тоже зависят от запроса ... ни в одном нет проверки на IS NULL, как явный признак необходимости left join, и часто стоит WHERE 1=1, из чего делаю вывод, что они собраны "чем-то" (cakePHP - есть такой?) и надо ли там именно левый джойн - не очевидно.

Каждый такой тормозной запрос перелопачивает от миллиона записей. Часто результат к возврату - отсутствует. То есть результат выборки - пуст.

Как понимаю, именно тут и создаются временные таблички.

masterZiv,

Вы на сайт ходили? Зачем рекомендовать человеку заведомо неграмотное решение? В каких конкретно случаях разнесение клиента и сервера БД дает прирост производительности? Как часто такое у означенных сайтов?

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

Там надо всё возвращать на один комп и заниматься оптимизацией запросов, устраняя левые соединения везде где они не востребованы по задаче клиента.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839338
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109miksoft,

Я его выкачивать не стал, не увидел в нем ничего такого, кроме регулярных запросов с большим временем выполнения, и они все идут с левым джойном к 3 и более таблицам. Главная - разная, вторая всегда users, третья и т.д. - тоже зависят от запроса ... ни в одном нет проверки на IS NULL, как явный признак необходимости left join, и часто стоит WHERE 1=1, из чего делаю вывод, что они собраны "чем-то" (cakePHP - есть такой?) и надо ли там именно левый джойн - не очевидно.

Каждый такой тормозной запрос перелопачивает от миллиона записей. Часто результат к возврату - отсутствует. То есть результат выборки - пуст.

Как понимаю, именно тут и создаются временные таблички.Что-то не догоняю, а зачем такого рода запросам дисковые временные таблицы? Там нет ORDER BY, GROUP BY, подзапросов, VIEW, агрегатных функций и т.п. ?
Что с планом? Не надо ли добавить индексов? Не применить ли покрывающие индексы (благо, что памяти для их кэширования достаточно)?
Хорошо бы еще порог попадания в slow-log снизить до секунды.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839569
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,

:) Эт, я забыл черкануть сюда. Конечно же есть любимый групбай... :)

В саму базу через клиента я не полез ибо нет смысла. Пока нет. То же самое и с сокращением времени slow log. Там надо сначала собрать всё на один комп, возможно дорастив ему оперативы (комп с сайтом - только 4 гектара), или обосновать и сделать полноценную реплику, потом прочистить запросы от левых джойнов и ненужных групбаев, потом надавать дизайнеру и верстальщику по шеям и разгрузить вес страниц (как Вы верно заметили, а я - упустил)

... итолько потом смотреть чего ишо можно улучшить. :)

Автору большую часть этого я отписал, свою консультацию провел ... а уж чего он решит, пусть сам.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839595
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109miksoft,

Я его выкачивать не стал, не увидел в нем ничего такого, кроме регулярных запросов с большим временем выполнения, и они все идут с левым джойном к 3 и более таблицам. Главная - разная, вторая всегда users, третья и т.д. - тоже зависят от запроса ... ни в одном нет проверки на IS NULL, как явный признак необходимости left join, и часто стоит WHERE 1=1, из чего делаю вывод, что они собраны "чем-то" (cakePHP - есть такой?) и надо ли там именно левый джойн - не очевидно.

Каждый такой тормозной запрос перелопачивает от миллиона записей. Часто результат к возврату - отсутствует. То есть результат выборки - пуст.

Мужчина, так вот и надо брать ПО ОДНОМУ эти вот запросы, и решать проблемы их производительности.
Бери сначала самый долгий. Не, не так. Частый (нужно знать приложение), но долгий. Т.е. если самый долгий -- редкий, его не бери.
Бери следующий по длительности, и так далее, пока не найдёшь часто выполняемый.
Его оптимизируй (надо понять, в чём проблема и её исправить).

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

ПОСЛЕ исправления -- очищаешь slow query log, ждёшь, когда он снова наполнится -- и снова повторяешь операцию (для следующего запроса).
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839608
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109Вы на сайт ходили?
.

Мне твой сайт ни к чему. GUI морда ни о чём не говорит.

Arhat109Зачем рекомендовать человеку заведомо неграмотное решение? В каких конкретно случаях разнесение клиента и сервера БД дает прирост производительности?


Всегда. Это повышает вычислительные мощности системы. Примерно в 2 раза, если одинаковые серваки.
Это не даст прирост только если у вас очень слабая загрузка, тогда производительность останется такой же.


Arhat109Как часто такое у означенных сайтов?

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


А что, у вас между компами не гигабитная сетка на волокне ?

Arhat109Там надо всё возвращать на один комп и заниматься оптимизацией запросов, устраняя левые соединения везде где они не востребованы по задаче клиента.

Не, ну, мужчина, как хочешь. Я тебе даю полезные советы, бесплатно, а там уж твоё дело, делать, как будет лучше, или себе же хуже.

Вообще, в принципе, когда БД и что-то ещё на одной машине -- производительность достаточно сложно отслеживать.
Даже в этом огромный плюс. Когда MySQL(или кто ещё) считает запрос, а тут поступает запрос в appach и он под себя берёт всё CPU вытесняя MySQL нафиг из проца, то тут что можно мониторить ?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839621
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109или обосновать и сделать полноценную реплику,

Реплика-то как производительности поможет ?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839640
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,

вот это: Всегда. Это повышает вычислительные мощности системы. Примерно в 2 раза, если одинаковые серваки.

обоснуйте тупому, желательно с цифирьками.

А также вы умолчали про соотношение скоростей передачи данных по внутренней петле в одном компе и гигабитной сетью, пусть даже в случае ровно двух компов, без чего либо ещё в этой сети.

Интересно Ваше мнение как специалиста. :)
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839731
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор Примерно в 2 раза, если одинаковые серваки.


а пацаны и не знают.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839816
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109MasterZiv,

вот это: Всегда. Это повышает вычислительные мощности системы. Примерно в 2 раза, если одинаковые серваки.

обоснуйте тупому, желательно с цифирьками.


Чего тебе обосновывать-то ?

У тебя один сервер. В нём скажем 16 гиг памяти и 8 процов.
Ты ставишь второй такой же -- суммарно получается 32 гиг памяти и 16 процов.

Скорость передачи данных между WEB-сервером и СУБД не должна быть такой уж критичной,
потому что от WEB-сервера в СУБД поступают запросы, их объём в видеданных маленький,
а обратно из СУБД в WEB-сервер идут только результаты этих запросов, которые также небольшие
по объему, если конечно приложение нормально спроектировано.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38839857
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,

Да... а пацаны-то и не знают. Пасибки. То есть, ежели я поставлю 100 веб-морд и 100 SQL серваков, то мой сайт будет шустрее ровно ... в 200 раз? Круть. (побежал за железом)

Вы так и НЕ ответили: во сколько РАЗ скорость гигабитной подсети промеж двух компов шустрее внутренней петли одного компа...

Почто так "игнорите"? :)
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840054
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да... а пацаны-то и не знают. Пасибки. То есть, ежели я поставлю 100 веб-морд и 100 SQL серваков, то мой сайт будет шустрее ровно ... в 200 раз? Круть. (побежал за железом)


при правильной архитектуре - да, почти в 200 раз.
по сравнению с одним таким компом и при бесконечно растущей нагрузке, естественно.

Вы так и НЕ ответили: во сколько РАЗ скорость гигабитной подсети промеж двух компов шустрее внутренней петли одного компа...

я тебе ответил, что скорость сети тебе особенно не важна. потому что там трафик не такой и большой.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840064
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,

Нет, так и НЕ ответили, а только виляете.

Ибо хорошо знаете, что скорость гигабитной сети никак не в состоянии превысить порог в 42 мегабайта в сек. (1000Мбит / 12бит / 2 - окно Ethernet), что даже ниже скорости средненького винчестера под виндой (60-80), а скорость внутренней петли измеряется сотнями метров, если не гектарами в ту же самую секунду. То есть это

самое медленное звено во всей последовательной(!) цепи обработки HTML-запроса (PHP_клиент - сеть - мускуль - ФС - мускуль - сеть - PHP_клиент).

А теперь следим за пальцами: был один сервер и он ... справлялся. Стало 2 и начались проблемы, что и явилось причиной появления автора тут... вы же пишете что его решение есть "хорошо".

Есть, и хорошо, но не для задач клиента.

Поэтому и спрашивал, в каких случаях это решение есть хорошо. Ни одного примера от Вас - не последовало, тока теория высосанная из пальца. А жаль.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840151
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторпри правильной архитектуре - да, почти в 200 раз.
а расскажите ка про эти секретные приборы?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840269
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторНет, так и НЕ ответили, а только виляете.

Ибо хорошо знаете, что скорость гигабитной сети никак не в состоянии превысить порог в 42 мегабайта в сек. (1000Мбит / 12бит / 2 - окно Ethernet), что даже ниже скорости средненького винчестера под виндой (60-80), а скорость внутренней петли измеряется сотнями метров, если не гектарами в ту же самую секунду. То есть это

самое медленное звено во всей последовательной(!) цепи обработки HTML-запроса (PHP_клиент - сеть - мускуль - ФС - мускуль - сеть - PHP_клиент).


Мужчина, ещё уже наверное 5-ый раз -- нет там между сервером приложений (WEB) и СУБД какого-то огромного траффика.
Не должно его просто быть в такой архитектуре. Он там мизерный.

авторА теперь следим за пальцами: был один сервер и он ... справлялся. Стало 2 и начались проблемы, что и явилось причиной появления автора тут... вы же пишете что его решение есть "хорошо".

Есть, и хорошо, но не для задач клиента.


Для клиента было бы хорошо, если бы он хоть один запрос опубликовал.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840272
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ScareCrowавторпри правильной архитектуре - да, почти в 200 раз.
а расскажите ка про эти секретные приборы?

Чё расказать та ?

Sharding, shared nothing cluster поищи, и почитай.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840404
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,

Ок, вьюноша. А какой траффик будем считать "огромным"?

Эта цепочка - строго последовательна. Скажем типовые значения времен:

таких цепочек на запрос в среднем около десятка:
а) PHP-клиент(1) - 3мсек
б) запрос по сети в Мускуль - 0,2мсек
в) Мускуль (парсинг запроса и подготовка) - 10мсек
г) Мускуль (выполнение запроса, типовое значение) если из кеша 10мсек.
д) возврат по сети 100 записей по 4кб каждая (часто ибо текстом) = 0,4Мб / 42Мб (гигабитка) = 10 мсек

Итого на цепочку = 3+0,2+10+10+10 = 33,2 мсек.

При этом доля времени сетевого интерфейса ... 10.2/33.2 = 30,7% ... да и правда, не огромное время

, так мелочь.

Вот этой трети в данном случае и НЕ ХВАТИЛО.

Не советуйте того, в чем не разбираетесь.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840445
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор42 мегабайта в сек. (1000Мбит / 12бит / 2 - окно Ethernet)Что за странный расчет? А то, что я своими глазами вижу скорость копирования файлов с 80-90 Мбайт/с (да еще плюс накладные расходы на самбу и т.п.) - мираж?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840499
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft,

:) Согласно стандарту Ethernet-1000TX, да и всего Ethernet. Передача должна иметь окно молчания в 50% - то бишь "половина". Передача идет в 12 бит на байт.

А где и чем смотрите и что у вас за оборудование?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840504
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109,

Впрочем, пусть даже в датацентрах стоит сетка с 100 метров в сек. Скорость хорошего винчестера.

Ну получится для кешированных запросов 15% потеря времени по сравнению с внутренней петлей одной машины... не принципиально. Всё равно это самое слабое звено.

Да даже на одном компе! Время получения результата - впрямую и сильно зависит от ... количества возвращаемых данных. Ибо внутренняя петля - тоже далеко не идеальное решение.

То есть, рекомендовать посадить клиента на один комп, а СУБД на другой - это тупо неграмотно.

Кстати, в озвученных словах про шардинг, таки применяются несколько иные подходы... и при других обстоятельствах.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840616
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109Передача должна иметь окно молчания в 50% - то бишь "половина". Передача идет в 12 бит на байт.Это если и было когда-то, то точно не в последние лет 20...
Arhat109А где и чем смотрите и что у вас за оборудование?Да тупо файл с сервака копирую.
Arhat109Ибо внутренняя петля - тоже далеко не идеальное решение.Дык вроде сокеты используют, когда все на одном компе. Они еще быстрее.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840619
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В целом предлагаю бессмысленные бодания насчет скорости завершить, и так уже наоффтопили.

По задаче топикстартера у кого-то какие-то дополнительные сведения, замечания, вопросы есть?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840672
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109А какой траффик будем считать "огромным"?


мегобайты
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38840679
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftВ целом предлагаю бессмысленные бодания насчет скорости завершить, и так уже наоффтопили.

По задаче топикстартера у кого-то какие-то дополнительные сведения, замечания, вопросы есть?

Так он не колется.
Запросы не даёт.
Так что -- нет, не будет.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38841060
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще один кусок офтопика...

а) PHP-клиент(1) - 3мсек
б) запрос по сети в Мускуль - 0,2мсек
в) Мускуль (парсинг запроса и подготовка) - 10мсек
г) Мускуль (выполнение запроса, типовое значение) если из кеша 10мсек.
д) возврат по сети 100 записей по 4кб каждая (часто ибо текстом) = 0,4Мб / 42Мб (гигабитка) = 10 мсек

это замечательный пример того, как не надо делать приложения.

пункты б-д вообще не должны существовать, если это предопределенные данные.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38841084
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MasterZiv,

Не знаю, кто и что там и кому "должен" или наоборот. Я привел типовой цикл работы веб приложений. Их таких 99.99% или около.

Согласен, давайте прекратим оффтоп. Объявится автор - можем спросить "чего оно сейчас", но мне кажется он уже на каникулах.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844341
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну вот. Автор отписался, что проблема найдена и решена. Сервер ДДОСился ... кроном. :)
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844350
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109Ну вот. Автор отписался, что проблема найдена и решена. Сервер ДДОСился ... кроном. :)
по крону бэкап делали?

почитал тут ваши разборки, так замечание -
1. использование localhost при коннекте к mysql дело нехорошее, что вы всё время про эту петлю ;)
2. К автору с его 300-400 пользователей в день конечно не относится (ИМХО исользуемое ими оборудование - деньги на ветер, хотя возможно это дешевле чем привести приложение в порядок), но самое узкое место всё-же файловая система ( что на сервере БД что на сервере приложения ) т.к. 60 Мб/с вы на ней не получите ( если обычные не SSD диски), даже с хорошим кэширующим рэйдом.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844352
tanglir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109, тогда, наверное, не ДДОСился, а ДОСился?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844365
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
tanglir,

Да фиг его знает как верно... :)

Там в кроне как раз и сидел тот генератор запросов, который с левыми джойнами и группировками, как понимаю. Просто "до" разделения он гонялся скажем так "изредка", а при переносе, видимо его перенастроили "не так" и он начал исполняться очень часто, чем и подвесил всю систему, при столь низкой нагрузке. Это со слов автора.

Тем не менее, вопрос оптимизации запросов, ИМХО, там стоит явно.

По-поводу петли - безусловно плохо. Но, сколько раз поднимал Мускуль, столько раз видел её траблы при настройках по умолчанию. Большинство также часто гоняет Мускуль в типовом конфиге "не заморачиваясь". Так что вопрос - актуален.

Насчет HDD - категорически не согласен. Нормальные серверные, а не бытовые винты, дают скорость обмена в районе 120-150 Мб/сек. А в рейде - вполне реально получать до 250Мб/сек. и более. Сам делал эксперимент с рейд-0 о 4-х винтах (больше не было) и нормальном raid-контроллере... получить скорость под 400 метров в сек - вполне реально. Другой вопрос надежности такой системы, но это - таки другой вопрос. Но, опять же. Если это slave реплика только на чтение - то и пофиг. :)

Типовые решения - далеко не всегда "Айс"...
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844374
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109tanglir,

Да фиг его знает как верно... :)

Там в кроне как раз и сидел тот генератор запросов, который с левыми джойнами и группировками, как понимаю. Просто "до" разделения он гонялся скажем так "изредка", а при переносе, видимо его перенастроили "не так" и он начал исполняться очень часто, чем и подвесил всю систему, при столь низкой нагрузке. Это со слов автора.

Тем не менее, вопрос оптимизации запросов, ИМХО, там стоит явно.

По-поводу петли - безусловно плохо. Но, сколько раз поднимал Мускуль, столько раз видел её траблы при настройках по умолчанию. Большинство также часто гоняет Мускуль в типовом конфиге "не заморачиваясь". Так что вопрос - актуален.

Насчет HDD - категорически не согласен. Нормальные серверные, а не бытовые винты, дают скорость обмена в районе 120-150 Мб/сек. А в рейде - вполне реально получать до 250Мб/сек. и более. Сам делал эксперимент с рейд-0 о 4-х винтах (больше не было) и нормальном raid-контроллере... получить скорость под 400 метров в сек - вполне реально. Другой вопрос надежности такой системы, но это - таки другой вопрос. Но, опять же. Если это slave реплика только на чтение - то и пофиг. :)

Типовые решения - далеко не всегда "Айс"...

диски: вы мерили не случайный доступ, и не "во много потоков"...
mysql после 5.4 или даже раньше ( в том числе драйвера) при написании localhost используют socket, в документации вроде так было :) так сказать подумали за массовых пользователей ( ИМХО не нужно так делать )
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844380
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81,

Я разный доступ мерял... :)

Насчет Мускуля 5.4 - ничего сказать не могу. Последний, который пользую - 5.1. как самый шустрый. :)
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844386
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Arhat109NikolayV81,

Я разный доступ мерял... :)

Насчет Мускуля 5.4 - ничего сказать не могу. Последний, который пользую - 5.1. как самый шустрый. :)
с fork-ами сравнивали, или у вас myisam?
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844400
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81,

Иннодебил, и был xtraDb в одном проекте. MyISAM - не СУБД ни разу. Уже обсуждалось, холиварить незачем. В смысле отвечать не буду. :)
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844452
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81

mysql после 5.4 или даже раньше ( в том числе драйвера) при написании localhost используют socket, в документации вроде так было :) так сказать подумали за массовых пользователей ( ИМХО не нужно так делать )

Ну так прежде чем писать уточните это в документации. На не существовавшую версию 5.4.

Сокеты - это тип интерфейса для межпроцессной коммуникации. В unix mysql сокеты использует обязательно, но разных типов.
Cокеты типа unix, которые использует mysql при указании специального имени "localhost" несколько проще в реализации и поэтому немного быстрее. Ничего там не поменялось.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844505
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netwindNikolayV81
mysql после 5.4 или даже раньше ( в том числе драйвера) при написании localhost используют socket, в документации вроде так было :) так сказать подумали за массовых пользователей ( ИМХО не нужно так делать )

Ну так прежде чем писать уточните это в документации. На не существовавшую версию 5.4.

Сокеты - это тип интерфейса для межпроцессной коммуникации. В unix mysql сокеты использует обязательно, но разных типов.
Cокеты типа unix, которые использует mysql при указании специального имени "localhost" несколько проще в реализации и поэтому немного быстрее. Ничего там не поменялось.

С версиями не угадал ;)
про немного, сложно сказать...
http://osnet.cs.binghamton.edu/publications/TR-20070820.pdf
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844525
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NikolayV81
С версиями не угадал ;)

а с чем угадали?

очевидно, что одни способы обмена лучше чем другие, но на фоне затрат на собственно обработку запросов, это теряется.
...
Рейтинг: 0 / 0
Срочно нужна помощь с оптимизацией INNODB
    #38844527
NikolayV81
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
netwindNikolayV81С версиями не угадал ;)

а с чем угадали?

очевидно, что одни способы обмена лучше чем другие, но на фоне затрат на собственно обработку запросов, это теряется.

Тут по ветке выше...
В принципе по сравнению со временем существования мира, любой отрезок времени доступный человеку не является существенным :)
...
Рейтинг: 0 / 0
71 сообщений из 71, показаны все 3 страниц
Форумы / MySQL [игнор отключен] [закрыт для гостей] / Срочно нужна помощь с оптимизацией INNODB
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]