Closed Armin83 closed 6 years ago
wait much more without innodb
Well, your issue may be solved migrating to innodb... This is not required right now, but this will be in the future, since we may rely on innodb only capabilities. So, do the switch anyways.
Yes but this only query blocks all other in my system also with innodb all other session are waiting
Well, that was not clear in your initial message.
Search query depends on search parameters of course, but also on display parameters for current user. Take a look at those to see which one make this query so huge.
Only minimum fields
No one is working:
MariaDB [(none)]> show open tables WHERE In_use > 0;
Empty set (0.01 sec)
I start the only the search.
MariaDB [(none)]> show open tables where in_use > 0;
+----------+--------------------------+--------+-------------+
| Database | Table | In_use | Name_locked |
+----------+--------------------------+--------+-------------+
| glpidb | glpi_itilsolutions | 3 | 0 |
| glpidb | glpi_suppliers | 1 | 0 |
| glpidb | glpi_items_tickets | 1 | 0 |
| glpidb | glpi_olalevels | 1 | 0 |
| glpidb | glpi_slalevels | 1 | 0 |
| glpidb | glpi_tickettasks | 1 | 0 |
| glpidb | glpi_locations | 1 | 0 |
| glpidb | glpi_tickets_users | 3 | 0 |
| glpidb | glpi_objectlocks | 1 | 0 |
| glpidb | glpi_ticketvalidations | 1 | 0 |
| glpidb | glpi_documents_items | 1 | 0 |
| glpidb | glpi_users | 12 | 0 |
| glpidb | glpi_slalevels_tickets | 1 | 0 |
| glpidb | glpi_suppliers_tickets | 1 | 0 |
| glpidb | glpi_olalevels_tickets | 1 | 0 |
| glpidb | glpi_ticketcosts | 1 | 0 |
| glpidb | glpi_documents | 1 | 0 |
| glpidb | glpi_ticketsatisfactions | 1 | 0 |
| glpidb | glpi_tickets_tickets | 4 | 0 |
| glpidb | glpi_ticketfollowups | 1 | 0 |
| glpidb | glpi_solutiontypes | 1 | 0 |
| glpidb | glpi_tasktemplates | 1 | 0 |
| glpidb | glpi_tickets | 4 | 0 |
| glpidb | glpi_groups | 4 | 0 |
| glpidb | glpi_groups_tickets | 3 | 0 |
| glpidb | glpi_taskcategories | 1 | 0 |
| glpidb | glpi_itilcategories | 1 | 0 |
| glpidb | glpi_problems_tickets | 1 | 0 |
| glpidb | glpi_slas | 2 | 0 |
| glpidb | glpi_olas | 2 | 0 |
| glpidb | glpi_requesttypes | 2 | 0 |
| glpidb | glpi_entities | 1 | 0 |
+----------+--------------------------+--------+-------------+
32 rows in set (0.00 sec)
I did a better test.
I think it is normal that if i use the same browser (with innodb). that a second tab hangs until i have the search result in the first tab or isn't it ? (but this is no problem for me so we could imho close my issue)
There are known historical issues on large "locks" with myisam, so yes, this seems "normal". All of this seems sql server issues, not directly related to GLPI. Tests on MYISAM are useless. InnoDB will become the only supported engine; and a well working script to do the migration is provided. This has not been automated just for users can plan (since this may take some time on huge instances).
If I've understand (what you said is still not clear to me); you are facing a MYISAM lock issue; solution for that is to migrate to INNODB.
@Armin83
I think it is normal that if i use the same browser (with innodb). that a second tab hangs until i have the search result in the first tab or isn't it ?
It is normal. PHP locks the session file when a session has been opened by a script, until script finishes or a call to session_write_close()
is made (See http://php.net/manual/en/session.examples.basic.php). So if you open multiple pages using the same session (defined by the session cookie value), requests will be queued.
@cedric-anne Thanks - i will wait vor 9.3.2 and then i upgrade to mariadb and innodb too.
Steps to reproduce (which actions have you made) : Ticket querry on "ALL"
Expected result : The other users can work with glpi. The user who did the query is the only one who have to wait.
Actual result : No session from glpi ist working all processes waiting for the one sql command
URL of the page : http://192.168.1.108/front/ticket.php?is_deleted=0&as_map=0&criteria%5B0%5D%5Bfield%5D=12&criteria%5B0%5D%5Bsearchtype%5D=equals&criteria%5B0%5D%5Bvalue%5D=all&criteria%5B1%5D%5Blink%5D=AND&criteria%5B1%5D%5Bfield%5D=all&criteria%5B1%5D%5Bsearchtype%5D=contains&criteria%5B1%5D%5Bvalue%5D=TESTTESTTESTTEST&search=Search&itemtype=Ticket&start=0&_glpi_csrf_token=f33af9cc064bd51cfd16d8670b4ecde7
Screenshot of the problem (if pertinent) :
the query - NOW with innodb on my test system all users only have to wait for 14 second but on production system all users wait much more without innodb Is this normal, bug or mysql / mariadb / ubuntu problem ?
[code] GLPI 9.3.1 ( => /var/www/glpi) Installation mode: TARBALL
Operating system: Linux glpidev 4.15.0-34-generic #37-Ubuntu SMP Mon Aug 27 15:21:48 UTC 2018 x86_64 PHP 7.2.10-0ubuntu0.18.04.1 apache2handler (Core, PDO, Phar, Reflection, SPL, SimpleXML, Zend OPcache, apache2handler, apc, apcu, calendar, ctype, curl, date, dom, exif, fileinfo, filter, ftp, gd, gettext, hash, iconv, imagick, imap, intl, json, ldap, libxml, mbstring, memcache, mysqli, mysqlnd, openssl, pcre, pdo_mysql, pdo_sqlite, posix, pspell, readline, recode, session, shmop, sockets, sodium, sqlite3, standard, sysvmsg, sysvsem, sysvshm, tidy, tokenizer, wddx, xml, xmlreader, xmlrpc, xmlwriter, xsl, zlib) Setup: max_execution_time="30" memory_limit="128M" post_max_size="8M" safe_mode="" session.save_handler="files" upload_max_filesize="2M" Software: Apache/2.4.29 (Ubuntu) (Apache/2.4.29 (Ubuntu) Server at 192.168.1.108 Port 80) Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36 Server Software: Ubuntu 18.04 Server Version: 10.1.34-MariaDB-0ubuntu0.18.04.1 Server SQL Mode: Parameters: glpidbuser@localhost/glpidb Host info: Localhost via UNIX socket mysqli extension is installed ctype extension is installed fileinfo extension is installed json extension is installed mbstring extension is installed zlib extension is installed curl extension is installed gd extension is installed simplexml extension is installed xml extension is installed ldap extension is installed imap extension is installed Zend OPcache extension is installed APCu extension is installed xmlrpc extension is installed CAS extension is not present Database version seems correct (10.1.34) - Perfect! /var/www/glpi/files/_log : OK /var/www/glpi/config : OK /var/www/glpi/files : OK /var/www/glpi/files/_dumps : OK /var/www/glpi/files/_sessions : OK /var/www/glpi/files/_cron : OK /var/www/glpi/files/_graphs : OK /var/www/glpi/files/_lock : OK /var/www/glpi/files/_plugins : OK /var/www/glpi/files/_tmp : OK /var/www/glpi/files/_cache : OK /var/www/glpi/files/_rss : OK /var/www/glpi/files/_uploads : OK /var/www/glpi/files/_pictures : OK Web access to the files directory should not be allowed Check the .htaccess file and the web server configuration.
htmLawed version 1.2.4 in (/var/www/glpi/lib/htmlawed) SimplePie version 1.5.2 in (/var/www/glpi/vendor/simplepie/simplepie/library) TCPDF version 6.2.17 in (/var/www/glpi/vendor/tecnickcom/tcpdf) michelf/php-markdown in (/var/www/glpi/vendor/michelf/php-markdown/Michelf) true/punycode in (/var/www/glpi/vendor/true/punycode/src) iacaml/autolink in (/var/www/glpi/vendor/iamcal/lib_autolink) sabre/vobject in (/var/www/glpi/vendor/sabre/vobject/lib)
Server: 'dcsdf.xy.de', Port: '389', BaseDN: 'dc=dfad, dc=de', Connection filter: '(&(objectClass=user)(objectCategory=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))', RootDN: 'cn=IT-Support, cn=Users, dc=sdsfsa, dc= de', Use TLS: none
Not active
Way of sending emails: SMTP (anonymous@smtprelay.dafssdfads.de)
Name: 'it-support@dafsdfd.de' Active: Yes Server: '{e24324x.dfasdfasdf.de:993/imap/ssl/novalidate-cert/notls}' Login: 'glpdafsdi@dfasdfasdf.de' Password: Yes
news Name: Alarme Version: 1.3.2.4 State: To be cleaned barcode Name: Barcode Version: 0.90+1.0 State: To be cleaned reports Name: Berichte Version: 1.7.2 State: To be cleaned dashboard Name: Dashboard Version: 0.8.1 State: To be cleaned datainjection Name: File injection Version: 2.3.1 State: To be cleaned formcreator Name: Formulare Version: 2.6.3 State: To be cleaned addressing Name: IP Adressierung Version: 2.3.0 State: To be cleaned mreporting Name: More Reporting Version: 1.3.1 State: To be cleaned pdf Name: PDF-Ausgabe Version: 1.1 State: To be cleaned ticketcleaner Name: Ticket Cleaner Version: 2.0.4 State: To be cleaned [/code]