LINUX.ORG.RU

Задержка в связке php-mysql


0

1

Здравствуйте! Был затеян перенос web-сервера. Старый сервер:

:~$ mysql -V
mysql  Ver 14.14 Distrib 5.1.63, for debian-linux-gnu (i486) using readline 6.1
:~$ php -v
PHP 5.3.2-1ubuntu4.18 with Suhosin-Patch (cli) (built: Sep 12 2012 19:33:42) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with XCache v1.3.0, Copyright (c) 2005-2009, by mOo 
~$ apache2 -v
Server version: Apache/2.2.14 (Ubuntu)
Server built:   Mar  5 2012 16:41:39
Новый сервер:
:/etc/mysql# mysql -V
mysql  Ver 14.14 Distrib 5.5.37, for debian-linux-gnu (x86_64) using readline 6.2
:/etc/mysql# php -v
PHP 5.3.10-1ubuntu3.11 with Suhosin-Patch (cli) (built: Apr  4 2014 01:30:04) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with XCache v1.3.2, Copyright (c) 2005-2011, by mOo
:/etc/mysql# apache2 -v
Server version: Apache/2.2.22 (Ubuntu)
Server built:   Apr 17 2014 21:49:25
На старом стоит ispconfig2, на новом - ispconfig3. Во время переноса были скопированы со старого так же php.ini и my.cnf. Проблема в том, что во время выполнения запроса
$sql="
   INSERT  INTO items 
   SET ItemId='".$val['ItemId']."', 
   ItemName='".mysql_real_escape_string($val['ItemName'])."', 
   ItemType='".$val['cat']."', 
   ItemCategoryId='".mysql_real_escape_string($val['ItemCategoryId'])."', 
   DateNovelty='".mysql_real_escape_string($val['DateNovelty'])."', 
   Mel_Article='".mysql_real_escape_string($val['Mel_Article'])."', 
   Char1='".mysql_real_escape_string($val['Char1'])."', 
   Char2='".mysql_real_escape_string($val['Char2'])."', 
   Char3='".mysql_real_escape_string($val['Char3'])."', 
   Char4='".mysql_real_escape_string($val['Char4'])."', 
   
   Char5='".mysql_real_escape_string($val['Char5'])."', 
   Char6='".mysql_real_escape_string($val['Char6'])."', 
   Char7='".mysql_real_escape_string($val['Char7'])."', 
   Char8='".mysql_real_escape_string($val['Char8'])."', 
   Char9='".mysql_real_escape_string($val['Char9'])."', 
   
   ".($val['ItemType']=='Книги'?"BarCode='".mysql_real_escape_string($val['BarCode'])."',":"")." 
   price='".$val['Price']."' ,  
   price_opt='".$val['price_opt']."', 
   price_tt='".$val['price_tt']."', 
   prime_price='".$val['prime_price']."',  
   date_of_adding=CURRENT_DATE(), 
   date_of_update=CURRENT_DATE(), 
   remains='".$val['Qty']."', 
   remains_non_almaty='".$val['Qty_NonAlmaty']."', 
   remains_all='".$val['Qty_All']."',
   status=0, 
   new=1, 
   rating='".$val['rating']."', 
   platform='".$platform."', 
   rasprodaja='".$val['rasprodaja']."', 
   real_type='".$val['real_type']."',
   bonus='".$val['bonus']."'";
  // vd($sql);
   mysql_query($sql);
   if($e= mysql_error())
   {
    $sql="
    UPDATE items 
    SET ItemName='".mysql_real_escape_string($val['ItemName'])."',  
    ItemType='".$val['cat']."', 
    price='".$val['Price']."', 
    price_opt='".$val['price_opt']."', 
    price_tt='".$val['price_tt']."', 
    prime_price='".$val['prime_price']."',  
    DateNovelty='".mysql_real_escape_string($val['DateNovelty'])."', 
    ItemCategoryId='".mysql_real_escape_string($val['ItemCategoryId'])."',  
    BarCode='".mysql_real_escape_string($val['BarCode'])."',
    Char1='".$val['Char1']."',  
    Char2='".$val['Char2']."', 
    Char3='".$val['Char3']."', 
    Char4='".$val['Char4']."', 
    
    Char5='".mysql_real_escape_string($val['Char5'])."', 
    Char6='".mysql_real_escape_string($val['Char6'])."', 
    Char7='".mysql_real_escape_string($val['Char7'])."', 
    Char8='".mysql_real_escape_string($val['Char8'])."', 
    Char9='".mysql_real_escape_string($val['Char9'])."', 
    
    Mel_Article='".mysql_real_escape_string($val['Mel_Article'])."', 
    remains='".$val['Qty']."', 
    remains_non_almaty='".$val['Qty_NonAlmaty']."', 
    remains_all='".$val['Qty_All']."',
    rating='".$val['rating']."', 
    platform='".$platform."', 
    rasprodaja='".$val['rasprodaja']."', 
    real_type='".$val['real_type']."',
    bonus='".$val['bonus']."',
    date_of_update=CURRENT_DATE()
     
    WHERE ItemId='".$val['ItemId']."'";
на старом занимает значительно меньшее время на updаte/insert одного поля на старом (извиняюсь за проблемы с кодировкой)
<div style="margin: 10px; padding: 15px; background: #ececec"><b>85</b> - <b>�^��^��^��^��^��^��^��$
                        <br>�^�а ви�^��^�ин�^�: не н�^�жно! (0 s.)
                        <br>�^� �^�абли�^��^� <b>items</b>:(UPDATE) - <b>ok</b>(0.001 s.)
                        <br>�^�бновл�^�ем да�^��^� �^�елизов: <b>OK</b>(0 s.)<br>(0.001 s.)

на новом
 <div style="margin: 10px; padding: 15px; background: #ececec"><b>99</b> - <b>NIGHTWISH END OF INNOCENCE$
                        <br>На витрину: не нужно! (0 s.)
                        <br>В таблицу <b>items</b>:(UPDATE) - <b>ok</b>(0.033 s.)
                        <br>Обновляем даты релизов: <b>OK</b>(0 s.)<br>(0.033 s.)
Эта разница вытекает в часы из-за кол-ва таких замен. Грешили и на хард и на mysql, но не одна из догадок не оправдалась. Новый сервер было решено поднять на гипервизоре, т.к. планируется поставить на него еще 1 сайт, с разными версиями пхп и правами доступа. KVM, жесткий диск - raw. скорость записи, и на гипервизоре, и на виртуальной машине одинаков. Kvm:
# dbench 20
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
12 of 20 processes prepared for launch   0 sec
20 of 20 processes prepared for launch   0 sec
releasing clients
  20       302   214.34 MB/sec  warmup   1 sec  latency 504.377 ms
  20       405   137.64 MB/sec  warmup   2 sec  latency 1375.662 ms
  20       473   105.96 MB/sec  warmup   3 sec  latency 2375.742 ms
  20       653   104.71 MB/sec  warmup   4 sec  latency 2970.139 ms
  20       664    84.06 MB/sec  warmup   5 sec  latency 3629.487 ms
  20       664    70.13 MB/sec  warmup   6 sec  latency 3695.700 ms
  20       739    60.63 MB/sec  warmup   7 sec  latency 2426.754 ms
  20       826    53.59 MB/sec  warmup   8 sec  latency 240.482 ms
  20      1239    52.53 MB/sec  warmup   9 sec  latency 231.872 ms
  20      1634    52.16 MB/sec  warmup  10 sec  latency 781.441 ms
  20      2169    49.77 MB/sec  warmup  11 sec  latency 318.159 ms
  20      2698    51.37 MB/sec  warmup  12 sec  latency 308.664 ms
виртуалка:
# dbench 20
dbench version 4.00 - Copyright Andrew Tridgell 1999-2004

Running for 600 seconds with load '/usr/share/dbench/client.txt' and minimum warmup 120 secs
12 of 20 processes prepared for launch   0 sec
20 of 20 processes prepared for launch   0 sec
releasing clients
  20       403   276.83 MB/sec  warmup   1 sec  latency 384.064 ms
  20       650   205.86 MB/sec  warmup   2 sec  latency 695.049 ms
  20       722   141.20 MB/sec  warmup   3 sec  latency 199.991 ms
  20       784   106.76 MB/sec  warmup   4 sec  latency 433.083 ms
  20       895    86.58 MB/sec  warmup   5 sec  latency 259.006 ms
  20      1448    83.38 MB/sec  warmup   6 sec  latency 230.043 ms
  20      2156    77.67 MB/sec  warmup   7 sec  latency 233.417 ms
  20      2736    77.82 MB/sec  warmup   8 sec  latency 260.758 ms
  20      3106    75.73 MB/sec  warmup   9 sec  latency 315.075 ms
  20      3604    73.45 MB/sec  warmup  10 sec  latency 353.819 ms
  20      4268    73.14 MB/sec  warmup  11 sec  latency 347.235 ms
  20      4329    67.30 MB/sec  warmup  12 sec  latency 246.600 ms
  20      4431    62.53 MB/sec  warmup  13 sec  latency 349.857 ms
  20      4862    62.00 MB/sec  warmup  14 sec  latency 254.599 ms
Виртуалке было выделено 8 процов и 15 гб оперативы. Параметры мускла увеличивались много раз в геометрическом порядке, вплоть до того что вся база могла уместиться в оперативе (8 гб) но скорости это не добавляло. Пока не был изменен сам запрос на новом сервере:
 $sql = "INSERT  INTO items 
   SET 
   ItemId   = '".$val['ItemId']."', 
   ItemName  = '".mysql_real_escape_string($val['ItemName'])."', 
   ItemType  = '".$val['cat']."', 
   ItemCategoryId = '".mysql_real_escape_string($val['ItemCategoryId'])."', 
   DateNovelty  = '".mysql_real_escape_string($val['DateNovelty'])."', 
   Mel_Article  = '".mysql_real_escape_string($val['Mel_Article'])."', 
   Char1   = '".mysql_real_escape_string($val['Char1'])."', 
   Char2   = '".mysql_real_escape_string($val['Char2'])."', 
   Char3   = '".mysql_real_escape_string($val['Char3'])."', 
   Char4   = '".mysql_real_escape_string($val['Char4'])."', 
   Char5   = '".mysql_real_escape_string($val['Char5'])."', 
   Char6   = '".mysql_real_escape_string($val['Char6'])."', 
   Char7   = '".mysql_real_escape_string($val['Char7'])."', 
   Char8   = '".mysql_real_escape_string($val['Char8'])."', 
   Char9   = '".mysql_real_escape_string($val['Char9'])."', 
   ".($val['ItemType']=='Книги'?"BarCode='".mysql_real_escape_string($val['BarCode'])."',":"")." 
   price   = '".$val['Price']."' ,  
   price_opt  = '".$val['price_opt']."', 
   price_tt  = '".$val['price_tt']."', 
   prime_price  = '".$val['prime_price']."',  
   date_of_adding = CURRENT_DATE(), 
   date_of_update = CURRENT_DATE(), 
   remains   = '".$val['Qty']."', 
   remains_non_almaty = '".$val['Qty_NonAlmaty']."', 
   remains_all  = '".$val['Qty_All']."',
   status   = 0, 
   new    = 1, 
   rating   = '".$val['rating']."', 
   platform  = '".$platform."', 
   rasprodaja  = '".$val['rasprodaja']."', 
   real_type  = '".$val['real_type']."',
   bonus   = '".$val['bonus']."'
   
   
   ON DUPLICATE KEY UPDATE
   
   ItemName  = '".mysql_real_escape_string($val['ItemName'])."',  
   ItemType  = '".$val['cat']."', 
   price   = '".$val['Price']."', 
   price_opt  = '".$val['price_opt']."', 
   price_tt  = '".$val['price_tt']."', 
   prime_price  = '".$val['prime_price']."',  
   DateNovelty  = '".mysql_real_escape_string($val['DateNovelty'])."', 
   ItemCategoryId = '".mysql_real_escape_string($val['ItemCategoryId'])."',  
   BarCode   = '".mysql_real_escape_string($val['BarCode'])."',
   Char1   = '".$val['Char1']."',  
   Char2   = '".$val['Char2']."', 
   Char3   = '".$val['Char3']."', 
   Char4   = '".$val['Char4']."', 
   Char5   = '".mysql_real_escape_string($val['Char5'])."', 
   Char6   = '".mysql_real_escape_string($val['Char6'])."', 
   Char7   = '".mysql_real_escape_string($val['Char7'])."', 
   Char8   = '".mysql_real_escape_string($val['Char8'])."', 
   Char9   = '".mysql_real_escape_string($val['Char9'])."', 
   Mel_Article  = '".mysql_real_escape_string($val['Mel_Article'])."', 
   remains   = '".$val['Qty']."', 
   remains_non_almaty = '".$val['Qty_NonAlmaty']."', 
   remains_all  = '".$val['Qty_All']."',
   rating   = '".$val['rating']."', 
   platform  = '".$platform."', 
   rasprodaja  = '".$val['rasprodaja']."', 
   real_type  = '".$val['real_type']."',
   bonus   = '".$val['bonus']."',
   date_of_update = CURRENT_DATE()";
По сути мы оставили все это дело на совесть мусклу, хотя это не совсем комильфо, но скорость обновы сравнялась.При этом:
log_slow_queries  = /var/log/mysql/mysql-slow.log
long_query_time  = 1
log-queries-not-using-indexes

/var/log/mysql/mysql-slow.log:
# Time: 140630 12:18:07
# User@Host: web13u1[web13u1] @ localhost []
# Query_time: 0.000387  Lock_time: 0.000103 Rows_sent: 257  Rows_examined: 257
use web13db1;
SET timestamp=1404109087;
select * from i_genre_adapter;
# Time: 140630 12:18:30
# User@Host: web13u1[web13u1] @ localhost []
# Query_time: 0.000236  Lock_time: 0.000085 Rows_sent: 13  Rows_examined: 13
SET timestamp=1404109110;
SELECT * FROM i_permanent_discounts__cats;
# User@Host: web13u1[web13u1] @ localhost []
# Query_time: 0.000294  Lock_time: 0.000061 Rows_sent: 657  Rows_examined: 657
SET timestamp=1404109110;
SELECT * FROM i_permanent_discounts__wares;
# Time: 140630 12:24:16
# User@Host: web13u1[web13u1] @ localhost []
# Query_time: 3.445066  Lock_time: 0.000063 Rows_sent: 261  Rows_examined: 261
SET timestamp=1404109456;
SHOW TABLE STATUS FROM `web13db1`;
# User@Host: web13u1[web13u1] @ localhost []
# Query_time: 3.517421  Lock_time: 0.000031 Rows_sent: 261  Rows_examined: 261
SET timestamp=1404109456;
SHOW TABLE STATUS FROM `web13db1`;
# User@Host: web13u1[web13u1] @ localhost []
# Query_time: 0.000891  Lock_time: 0.000027 Rows_sent: 1  Rows_examined: 9295
SET timestamp=1404109456;
SELECT COUNT(*) FROM `web13db1`.`cob_codes__codes`;

Отсюда вытекает мнение, что трабла в связке php-mysql.

Т.к. модули и конфиги идентичны, не могли бы вы накидать мнений, в чем может быть трабла?

Кидаю идею - на новом сервере база создалась не MyISAM а InnoDB и по умолчанию там включены транзакции автоматические т.е. после каждого инсерта закрывает транзакцию (это долго). Если массовые инсерты надо самому делать start transaction/ commit transaction.

hidden_4003
()
Ответ на: комментарий от hidden_4003

Спасибо за ответ! Провел это время в бессмысленной борьбе с нашим вебером, дабы заставить его добавить эту команду в код скрипта. Он отказался ссылаясь на то, что на старом и так работало. Решил пойти др путем. Сделал дамп базы. добавил в my.cnf default_storage_engine=MYISAM, удалил базу, создал и накатил на нее дамп. Думал так же сделать миграцию с одного типа таблиц на другой, но в нашей базе намешано и тех и этих, потому отказался от этой затеи. Все вышеописанные действия результата не дали. задержка осталась.

Tamplier
() автор топика
Ответ на: комментарий от Tamplier

Сложно сказать что-либо определенное поскольку неизвестна структура таблицы и конфигурация сервера mysql.

Я бы тогда еще предложил на обоих серверах выполнить команду:

show variables;
и сравнить, вероятно какое-то значение по умолчанию поменялось между 5.1 и 5.5, или просто сборка неудачная можно еще пробовать percona или mariadb.

hidden_4003
()
Ответ на: комментарий от hidden_4003

Спасибо за помощь. Все настройки подогнал 1 к 1. Но как ни странно это не помогло. Во время сравнивания настроек обратил внимание на innodb_flush_log_at_trx_commit, которые у обоих стояли на 1. Я уже пробовал етот пункт выставлять 2 на новом, но тогда не дало результатов. Попробовал заново... И получилось. Видимо помог какой то стак настроек из нововыставленных. Еще раз спасибо за помощь.

Tamplier
() автор топика
Ответ на: комментарий от Tamplier

innodb_flush_log_at_trx_commit = 1 - пишет транзакцию в лог сразу после того как вызвали COMMIT innodb_flush_log_at_trx_commit = 2 - пишет транзакцию в лог 1 раз в секунду, с этим значением есть риск потерять данные в случае краха сервера.

Поскольку этот параметр помог проблемы явно с дисками, видимо в kvm ограничены iops, если в табличках dbench сверху второй столбик это iops то там сразу видно что на kvm в 2 раза меньше. Настраивайте дисковую подсистему.

hidden_4003
()
Ответ на: комментарий от anonymous

В твоём мире нет легаси и вообще розовые пони срут радугой?

ritsufag ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.