Since yesterday my CPU has been eating more than 300% of my CPU whether the number of visitors increases of decreases the CPU usage remains the same.I am in NGinx Ubuntu 18.02 in digitalocean.I am totally new to NGinx and I could set up my server following the tutorial provided in the digitalocean site.
I have been running for approximately one month and everything was smooth,but yesterday suddenly MYSQL started eating all the CPU.I have Googled and even read some of the stackover solution but nothing seems to help me in understanding in how to fix it.They say we shoykd try running this or that but what how to actually use the result of obtain from running those command is never explained.For instance I followed solution provided on this MySQL high CPU usage but it hard for newbie to follow it I ran
SHOW PROCESSLIST;
and got many result like these
| Id | User | Host | db | Command | Time | State | Info |
+---------+---------------+-----------+-----------+---------+------+-------------------+------------------------------------------------------------------------------------------------------+
| 5015945 | root | localhost | NULL | Query | 0 | starting | SHOW PROCESSLIST |
| 5026029 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026036 | wordpressuser | localhost | wordpress | Query | 0 | Sending data | SELECT SQL_CACHE *
026038 | wordpressuser | localhost | wordpress | Query | 0 | Sending to client | SELECT SQL_CACHE *
| 5026039 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026041 | wordpressuser | localhost | wordpress | Query | 0 | Sending data | SELECT SQL_CACHE *
| 5026047 | wordpressuser | localhost | wordpress | Query | 0 | Sending data | SELECT SQL_CACHE *
| 5026048 | wordpressuser | localhost | wordpress | Query | 0 | Sending data | SELECT SQL_CACHE *
| 5026049 | wordpressuser | localhost | wordpress | Query | 0 | Sending data | SELECT SQL_CACHE *
| 5026050 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026051 | wordpressuser | localhost | wordpress | Query | 0 | Sending data | SELECT SQL_CACHE *
| 5026052 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026053 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026054 | wordpressuser | localhost | wordpress | Query | 0 | init | SELECT tr.object_id FROM wp_term_relationships AS tr INNER JOIN wp_term_taxonomy AS tt ON tr.term_ta |
| 5026055 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026056 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026057 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026058 | wordpressuser | localhost | wordpress | Sleep | 0 | | NULL |
| 5026059 | wordpressuser | localhost | wordpress | Query | 0 | Sending data | SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (101,50,67,288,74,103,330,107 |
+---------+---------------+-----------+-----------+---------+------+-------------------+------------------------------------------------------------------------------------------------------+"
but how do exactly verify which is causing the issue? There may be others causing the issue but how do I determined it?
Can some please guide me of provide me some tutorial links that me guide me through this process from the ground up?
thank you.
Related
Sorry for the difficult description, but I know of no better way to say it.
When I look in certain tables of a MySQL database through the phpMyAdmin web interface, the numbers of the first two columns are prefixed by a '3'.
So if the first column has number 99, phpMyAdmin displays 3939.
The second column has number 3592, phpMyAdmin shows 33353932.
If I check the records with the mysql CLI they are displayed correctly.
It only happens to some columns in some tables of some databases... not to all.
So it might be something with the tables themselves or something with phpMyAdmin.
System/version info:
Ubuntu 16.04.3 LTS
phpmyadmin 4:4.5.4.1-2ubuntu2
apache2 2.4.18-2ubuntu3.5
php7.0 7.0.22-0ubuntu0.16.04.1
oracle-java9 9.0.1-1~webupd8~0
mysql-server 5.7.20-0ubuntu0.16.04.1
I'm hoping someone has some idea of what might be happening here.
If you wish any further clarification please let me know.
mysql CLI:
+------------------------------+
| Tables_in_gsb |
+------------------------------+
| gsb_challenge |
| gsb_challenge_pos |
| gsb_challenge_scope |
| gsb_copyright |
| gsb_correction |
| gsb_correction_gold |
| gsb_correction_literality |
| gsb_correction_sentalign |
| gsb_correction_tag |
| gsb_correction_tokenization |
| gsb_correction_wordalign |
| gsb_doc_counts |
| gsb_doc_status |
| gsb_doc_warnings |
| gsb_documents |
| gsb_log |
| gsb_reports_verbnet |
| gsb_semlex_entry |
| gsb_semlex_entry_cooc_cat |
| gsb_semlex_entry_cooc_lemma |
| gsb_semlex_entry_cooc_ne |
| gsb_semlex_entry_cooc_pos |
| gsb_semlex_entry_cooc_roles |
| gsb_semlex_entry_name |
| gsb_semlex_occurrence |
| gsb_status_flag |
| gsb_subcorpus |
| gsb_synsets |
| gsb_user |
| gsb_userCake_Groups |
| gsb_userCake_Users |
| gsb_v_accepted_docs |
| gsb_v_last_doc_status |
| gsb_v_last_doc_update |
| pmb_annotation_status |
| pmb_correction |
| pmb_correction_sentalign |
| pmb_correction_tag |
| pmb_correction_tokenization |
| pmb_dmatch |
| pmb_doc_counts |
| pmb_doc_lists |
| pmb_doc_status |
| pmb_doc_warnings |
| pmb_documents |
| pmb_lrec |
| pmb_lrec_dmatch |
| pmb_lrec_dmatch_backup |
| pmb_lrec_promatch |
| pmb_promatch |
| pmb_promatch_copy |
| pmb_reports_verbnet |
| pmb_semlex_entry |
| pmb_semlex_entry_cooc_cat |
| pmb_semlex_entry_cooc_lemma |
| pmb_semlex_entry_cooc_pos |
| pmb_semlex_entry_cooc_roles |
| pmb_semlex_entry_cooc_semtag |
| pmb_semlex_occurrence |
| pmb_status_flag |
| pmb_subcorpus |
| pmb_synsets |
| pmb_synsets_new |
| pmb_userCake_Groups |
| pmb_userCake_Users |
| pmb_v_phrase_search |
+------------------------------+
SELECT * FROM pmb_semlex_occurrence ORDER BY part DESC LIMIT 10;
+------+--------+-------+------+------+--------+------+----------------+------+----+-----------+---------+-----------+--------+--------+--------+----------+----------------------------------+
| part | doc_id | tokid | from | to | toknum | snum | cat | pos | ne | roles | wordnet | wordsense | semtag | lemma | token | token_lc | entry_id |
+------+--------+-------+------+------+--------+------+----------------+------+----+-----------+---------+-----------+--------+--------+--------+----------+----------------------------------+
| 99 | 3592 | 15056 | 2202 | 2203 | 453 | 15 | (N/PP)\(N/PP) | LQU | | [] | O | O | NIL | " | " | " | 594f1919d740100ed2f3e4cfd4100329 |
| 99 | 3592 | 15055 | 2201 | 2202 | 452 | 15 | (N/PP)\(N/PP) | . | | [] | O | O | NIL | . | . | . | 594f1919d740100ed2f3e4cfd4100329 |
phpmyadmin:
It's not my database, I only maintain the server it's running on, so I don't think it's a prank... and how would they even do that?
With the additional information that these columns are of BINARY type I was able to find two bug reports describing this behaviour:
broken view of binary fields (every second three)
broken link to table of binary fields (every second three)
The first should have been resolved in phpMyAdmin 4.3, but I see that you're using version 4.5. The related second issue was reported against version 4.7.1 and fixed in version 4.7.3.
Try upgrading to phpMyAdmin 4.7.3 or later (at the time of writing the latest version is 4.7.7).
Im having a very bizarre problem with a magento store that I work on. I have been doing the SEO and have about 100 404 errors for product urls that SHOULD be valid.
I can see the products and the urls in the product catalog via the admin - everything is correct there. If I try to load the product by its url key using the product model I get the correct product back (a configurable product with id 12457 - this is important for later).
But if I try to load the page by the url path - it wont load - instead I get a 404 error - even with developer mode - I get no insight into the issue as there isnt really ANYTHING to follow in the system.log or in the Varien profiler / debugger except the normal noRouteAction stuff that comes up.
So I started investigating the core_url_rewrites table to see if I could identify multiple (duplicate) urls. Sure enough - I did. The core_url_rewrite table had over 30000 rows with 2.5x the # of products for the product group so I deleted the rows in the table and reindexed.
This gave me the proper count of products - and I can see that there is a duplicate url issue of some sort:
+----------------+----------+--------------------+-------------------------------------------------------------------------------------------------+---------------------------------------------+-----------+---------+-------------+-------------+------------+
| url_rewrite_id | store_id | id_path | request_path | target_path | is_system | options | description | category_id | product_id |
+----------------+----------+--------------------+-------------------------------------------------------------------------------------------------+---------------------------------------------+-----------+---------+-------------+-------------+------------+
| 200513 | 1 | product/12279 | torano-exodus-1959-50-years-bfc-cigars.html | catalog/product/view/id/12279 | 1 | NULL | NULL | NULL | 12279 |
| 200514 | 1 | product/12280 | torano-exodus-1959-50-years-bfc-single-cigar.html | catalog/product/view/id/12280 | 1 | NULL | NULL | NULL | 12280 |
| 200759 | 1 | product/12408 | torano-exodus-1959-50-years-bfc.html | catalog/product/view/id/12408 | 1 | NULL | NULL | NULL | 12408 |
| 200760 | 1 | product/12408/8 | all-brands/torano-exodus-1959-50-years-bfc.html | catalog/product/view/id/12408/category/8 | 1 | NULL | NULL | 8 | 12408 |
| 200761 | 1 | product/12408/3535 | all-brands/torano-cigars/torano-exodus-1959-50-years/torano-exodus-1959-50-years-bfc.html | catalog/product/view/id/12408/category/3535 | 1 | NULL | NULL | 3535 | 12408 |
| 200762 | 1 | product/12408/3708 | all-brands/torano-cigars/torano-exodus-1959-50-years-bfc.html | catalog/product/view/id/12408/category/3708 | 1 | NULL | NULL | 3708 | 12408 |
| 200901 | 1 | product/12457 | torano-exodus-1959-50-years-bfc-12457.html | catalog/product/view/id/12457 | 1 | NULL | NULL | NULL | 12457 |
| 200902 | 1 | product/12457/3535 | all-brands/torano-cigars/torano-exodus-1959-50-years/torano-exodus-1959-50-years-bfc-12457.html | catalog/product/view/id/12457/category/3535 | 1 | NULL | NULL | 3535 | 12457 |
| 200903 | 1 | product/12457/3708 | all-brands/torano-cigars/torano-exodus-1959-50-years-bfc-12457.html | catalog/product/view/id/12457/category/3708 | 1 | NULL | NULL | 3708 | 12457 |
+----------------+----------+--------------------+-------------------------------------------------------------------------------------------------+---------------------------------------------+-----------+---------+-------------+-------------+------------+
It appears that product #12408 is taking the URL that belongs to 12457 - so logically I went to find product # 12408 to correct the issue - however - after searching the admin - as well as just querying the database there ISN'T an entity_id 12408 in catalog_product_flat_x that I can find.
This is obviously a problem - and at this point I dont know where to go looking for 12408 to either correct it or remove it so it stops breaking 12457's url.
Can anyone out there tell me how to fix this?
Thanks in Advance!
I need one help .I am trying to know last updated time of MySQL table .I used the below command.
show table status from spesh like 'db_restaurant_detail';
But i found the following result.
mysql> show table status from spesh like 'db_restaurant_detail';
+----------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+---------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time | Check_time | Collation | Checksum | Create_options | Comment |
+----------------------+--------+---------+------------+------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+---------+
| db_restaurant_detail | InnoDB | 10 | Compact | 1171 | 167 | 196608 | 0 | 0 | 5242880 | 7377 | 2016-04-26 08:34:47 | NULL | NULL | latin1_swedish_ci | NULL | | |
+----------------------+--------+---------+------------+------+----------------+-------------+-----------------
Here update_time is showing null. I need when user has updated data in this table.Please help me.
How can I detect on a production server which languages are available for stored procedures?
I can run sql queries from php and I have phppgadmin on the production server.
You can look at the pg_catalog.pg_language system table:
The catalog pg_language registers languages in which you can write functions or stored procedures.
So just some normal SQL is all you need:
=> select * from pg_catalog.pg_language;
lanname | lanowner | lanispl | lanpltrusted | lanplcallfoid | laninline | lanvalidator | lanacl
----------+----------+---------+--------------+---------------+-----------+--------------+--------
internal | 10 | f | f | 0 | 0 | 2246 |
c | 10 | f | f | 0 | 0 | 2247 |
sql | 10 | f | t | 0 | 0 | 2248 |
plpgsql | 10 | t | t | 11571 | 11572 | 11573 |
(4 rows)
The documentation should help you interpret the various columns.
I have this table in PostgreSQL:
appid | appname | apptype | creationtime | createdby | display
-------+-------------------------------------+---------+--------------+-----------+---------
0 | Custom | -1 | | | t
1000 | Performance/Resource | -2 | | | t
2000 | PING | 0 | | | t
2001 | HTTP | 0 | | | t
2002 | HTTPS | 0 | | | t
2003 | FTP | 0 | | | t
2004 | LDAP | 0 | | | t
2005 | IMAP | 0 | | | t
2006 | POP | 0 | | | t
2007 | SMTP | 0 | | | t
2008 | DNS | 0 | | | t
2009 | NFS | 0 | | | t
2010 | NTP | 0 | | | t
2011 | SSH | 0 | | | t
2012 | TCP | 0 | | | t
2013 | TELNET | 0 | | | t
3000 | Generic Mail (RTT) | 3 | | | t
3001 | Apache Tomcat | 2 | | | t
3002 | JBoss | 2 | | | t
3003 | MySQL | 1 | | | t
3004 | WebSphere | 2 | | | t
4000 | Microsoft Exchange Server 2003 | 3 | | | t
4001 | Exchange Server 2007 /2010 | 3 | | | t
4003 | Microsoft SQL Server 2008 | 1 | | | t
4004 | Microsoft ISA Server 2006 | 99 | | | t
4005 | Microsoft IIS | 4 | | | t
3005 | DB2 | 1 | | | t
3006 | Apache HTTP Server | 4 | | | t
3007 | Oracle | 1 | | | t
3008 | PostgreSQL | 1 | | | t
3009 | WebLogic | 2 | | | t
3010 | Adobe ColdFusion | 2 | | | t
3011 | Sybase | 1 | | | t
4007 | Microsoft SQL Server 2005 (EXPRESS) | 1 | | | t
4008 | Microsoft Team Foundation Server | 2 | | | t
4009 | Microsoft .NET | 99 | | | t
3012 | Apache Tomcat | 2 | | | f
Apache Tomcat repeats 2 times when this table shown in an dropdown. How do I disable the last row which is 3012? I have an option to delete it but this table is used in several places so I don't want to delete it.
I think the more important question is why is it in your database twice. Depending on what you're using this query for ignoring one could be just as wrong as deleting one. Maybe it has somehting to do with that being the only entry with display f. I guess you could just do WHERE display != 'f'
Tomcat appears twice because it's in the table twice, once with ID 3001 and again with ID 3012. I'd call that a problem with the data, not with the query. Does it really need to be there twice? You say you're reluctant to delete one of them because it's used in several places, but if you don't fix it now, it'll only be harder to fix later.
I'd focus on merging those duplicate rows. Find all the records (in other tables) that refer to one of this pair, and update them to refer to the other one instead. Then you can delete the one that nothing refers to anymore.
Why not use the display column? Sounds like it is for filtering out things that are not supposed to be shown. So, you could do a query like this:
SELECT appid, appname
FROM stat_applications
WHERE appid <> 0
AND appid <> 1000
AND display = 't'
If you don't want to use display, then you could just add 3012 to your list of things to ignore:
SELECT appid, appname
FROM stat_applications
WHERE appid <> 0
AND appid <> 1000
AND appid <> 3012
Or, since your exclusion list is getting longer, use NOT IN:
SELECT appid, appname
FROM stat_applications
WHERE appid NOT IN (0, 1000, 3012)