ncelikle long query'leri incele. Bu queryler içerisinde where ve join 'ler içerisinde geçen kolonları index olarak ekle. Service'e restart at Mysqltunner'i yukle. daha sonra 24 saat sistem çalışsın. 24 saatin sonunda mysqltunner i çalıştır ve sana tavsiye ettiği cache değerlerini my. cnf'ye gir.

wm-t bunu yazdı ncelikle long query'leri incele. Bu queryler içerisinde where ve join 'ler içerisinde geçen kolonları index olarak ekle. Service'e restart at Mysqltunner'i yukle. daha sonra 24 saat sistem çalışsın. 24 saatin sonunda mysqltunner i çalıştır ve sana tavsiye ettiği cache değerlerini my. cnf'ye gir. +1

10gb ram, 6 cpu, 120gb ssd zelliklerinde bir vps'im var. ram kullanımı 1gb'ın üzerine çıkmıyor. cpu kullanımı max. %2 şeklinde. fakat plesk üzerinde MySQL işlemcisi kullanımı 53.6% (600%, 6 çekirdek arasından) olarak grünmesine rağmen sorgular çok geç yanıt veriyor. tablo yapısı ve sorgularda bir problem yok diye var sayıyorum. satır sayısı 1 milyon civarında. bu tablo üzerinde insert ve select yapılıyor. bundan dolayı cache yapılması sanırım durumu daha da ktüleştirecek. plesk, php 7.2, nginx, phpfpm kullanıyorum; my. cnf üzerinde herhangi bir düzenleme yok. sunucuyu yeniden başlattıktan sonra aynı sorgular yapılmasına rağmen belli bir süre sunucu hızlanıyor. sunucuyu hızlandırmak için sizce nasıl bir yol izlemeliyim? hocam şyle yapabilirsin aslında geçmiş eski verileri exel ortamına aktarıp oradan çekersen daha verimli olur gibi şimdi bende de bir proje var aynı dert bende de var en mantıklısı exel gibi yatıyor kafama, site ne sitesi veriler public olsa sıkıntı olacakmı sana canısı| Keser gibi olma; hep bana, hep bana. Testere gibi ol Bir sana bir bana...

Vps kullanıyorsan io düşük olabilir. Senin sorunun sorgularınla alakalı. nce mysql cnf da slow query loglarını açacaksın. sonra sorgularının query planlarına bakacaksın. İndex vs tanımlarını yapacaksın. Datayı partitionlara ayıracaksın. Yoks cnf dosyasına iki parametre eklemekle o iş düzelmez. ftw

lepusmorris bunu yazdı 10gb ram, 6 cpu, 120gb ssd zelliklerinde bir vps'im var. ram kullanımı 1gb'ın üzerine çıkmıyor. cpu kullanımı max. %2 şeklinde. fakat plesk üzerinde MySQL işlemcisi kullanımı 53.6% (600%, 6 çekirdek arasından) olarak grünmesine rağmen sorgular çok geç yanıt veriyor. tablo yapısı ve sorgularda bir problem yok diye var sayıyorum. satır sayısı 1 milyon civarında. bu tablo üzerinde insert ve select yapılıyor. bundan dolayı cache yapılması sanırım durumu daha da ktüleştirecek. plesk, php 7.2, nginx, phpfpm kullanıyorum; my. cnf üzerinde herhangi bir düzenleme yok. sunucuyu yeniden başlattıktan sonra aynı sorgular yapılmasına rağmen belli bir süre sunucu hızlanıyor. sunucuyu hızlandırmak için sizce nasıl bir yol izlemeliyim? hocam şyle yapabilirsin aslında geçmiş eski verileri exel ortamına aktarıp oradan çekersen daha verimli olur gibi şimdi bende de bir proje var aynı dert bende de var en mantıklısı exel gibi yatıyor kafama, site ne sitesi veriler public olsa sıkıntı olacakmı sana hocam where kullandığım sütunlara index verdikten sonra baya bir performans artışı oldu ama yine de okuma yazma hızları beni tatmin etmiyor.io_capacity falan kurcalıyorum. anlık okuma yazma hızlarını kurcalıyorum şimdi. bu mysqltuner'in dediklerini de uyguladım ama pek fark yok gibi. hep aynı şeyleri neriyor. ilişkisel tablolar olmasa nosql deniycem direkt. kurcalaya kurcalaya baya yol aldım. ..

10gb ram, 6 cpu, 120gb ssd zelliklerinde bir vps'im var. ram kullanımı 1gb'ın üzerine çıkmıyor. cpu kullanımı max. %2 şeklinde. fakat plesk üzerinde MySQL işlemcisi kullanımı 53.6% (600%, 6 çekirdek arasından) olarak grünmesine rağmen sorgular çok geç yanıt veriyor. tablo yapısı ve sorgularda bir problem yok diye var sayıyorum. satır sayısı 1 milyon civarında. bu tablo üzerinde insert ve select yapılıyor. bundan dolayı cache yapılması sanırım durumu daha da ktüleştirecek. plesk, php 7.2, nginx, phpfpm kullanıyorum; my. cnf üzerinde herhangi bir düzenleme yok. sunucuyu yeniden başlattıktan sonra aynı sorgular yapılmasına rağmen belli bir süre sunucu hızlanıyor. sunucuyu hızlandırmak için sizce nasıl bir yol izlemeliyim? lepusmorris tarafından 23/May/18 15:57 tarihinde düzenlenmiştir..

wm-t bunu yazdı ncelikle long query'leri incele. Bu queryler içerisinde where ve join 'ler içerisinde geçen kolonları index olarak ekle. Service'e restart at Mysqltunner'i yukle. daha sonra 24 saat sistem çalışsın. 24 saatin sonunda mysqltunner i çalıştır ve sana tavsiye ettiği cache değerlerini my. cnf'ye gir. dediği nerileri yaptım ama 24 saatten fazla geçmesine rağmen hala aynı sonuçları veriyor. bir yerde hata mı yapıyorum? /etc/my. cnf'e eklediğim satırlar. query_cache_size = 0query_cache_type = 0query_cache_limit = 1Mjoin_buffer_size = 128Ktmp_table_size = 12Mmax_heap_table_size = 12Mthread_cache_size = 4table_open_cache = 300innodb_file_per_table = ONinnodb_buffer_pool_size = 5Ginnodb_log_file_size = 16M mysqltuner nerileri General recommendations:Control warning line into /var/log/mariadb/mariadb. log fileRestrict Host for user@% to user@SpecificDNSorIpEnable the slow query log to troubleshoot bad queriesConfigure your accounts with ip or subnets only, then update your configuration with skip-name-resolve=1Adjust your join queries to always utilize indexesWhen making adjustments, make tmp_table_size/max_heap_table_size equalReduce your SELECT DISTINCT queries which have no LIMIT clauseSet thread_cache_size to 4 as a starting valueIncrease table_open_cache gradually to avoid file descriptor limitsRead this before increasing table_open_cache over 64: http://bit.ly/1mi7c4CThis is MyISAM only table_cache scalability problem, InnoDB not affected. See more details here: https://bugs.mysql.com/bug. php?id=49177This bug already fixed in MySQL 5.7.9 and newer MySQL versions. Beware that open_files_limit (1024) variableshould be greater than table_open_cache (400)Consider installing Sys schema from https://github.com/mysql/mysql-sysBefore changing innodb_log_file_size and/or innodb_log_files_in_group read this: http://bit.ly/2wgkDvS Variables to adjust:query_cache_size (=0)query_cache_type (=0)query_cache_limit (> 1M, or use smaller result sets)join_buffer_size (> 128.0K, or always use indexes with JOINs)tmp_table_size (> 16M)max_heap_table_size (> 16M)thread_cache_size (start at 4)table_open_cache (> 400)innodb_file_per_table=ONinnodb_buffer_pool_size (>= 5G) if possible. innodb_log_file_size should be (=16M) if possible, so InnoDB total log files size equals to 25% of buffer pool size. ..

mysql versiyon eski ise cpu kullanımı düşük olabilir snnyk.com - code is poetry all that i know...