Skocz do zawartości

Syndrom

WHT Pro
 Wyświetl profil  Zobacz jego aktywność

  • Zawartość

    328

  • Rejestracja

  • Ostatnio

  • Wygrane dni

    5

Posty napisane przez Syndrom

  3. Napisano · Raportuj odpowiedź

    Zatrzymałem się w miejscu przy analizie, dlaczego okresowo zużycie procesora dla mysql skacze do 100%, co za tym zużycie procesora dla apacha skacze, ponieważ czeka na odpowiedzi od mysqla.

    # free -m
             total       used       free     shared    buffers     cached
Mem:         32071      31891        179          0       1008      29046
-/+ buffers/cache:       1836      30234

4x Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz

# du -sh /var/lib/mysql/
787M    /var/lib/mysql/

    Kiedy CPU skacze dla prcoesu do 100% sprawdzam listę procesów mysqla i nic tam nie ma:

    mysql> show full processlist;
+------+----------------+-----------+----------------+---------+------+-------+-----------------------+
| Id   | User           | Host      | db             | Command | Time | State | Info                  |
+------+----------------+-----------+----------------+---------+------+-------+-----------------------+
| 4501 | dofa_0          | localhost | dofa_0         | Sleep   | 3413 |       | NULL                  |
| 1255 | myroot          | localhost | NULL           | Query   |    0 | NULL  | show full processlist |
+------+----------------+-----------+----------------+---------+------+-------+-----------------------+
2 rows in set (0.00 sec)

    Mysql jest wystawiony na zewnątrz i może przez próby ataku load skacze ?

     

    Jeszcze co pokazuje mysqltunner.pl

    -------- Storage Engine Statistics -------------------------------------------
[--] Status: +CSV +InnoDB +MRG_MYISAM 
[--] Data in MyISAM tables: 550M (Tables: 1008)
[--] Data in InnoDB tables: 90M (Tables: 757)
[!!] Total fragmented tables: 758

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

-------- Performance Metrics -------------------------------------------------
[--] Up for: 11h 46m 41s (1B q [23K qps], 5K conn, TX: 165B, RX: 71B)
[--] Reads / Writes: 90% / 10%
[--] Total buffers: 818.0M global + 12.4M per thread (151 max threads)
[OK] Maximum possible memory usage: 2.6G (8% of installed RAM)
[OK] Slow queries: 0% (0/1B)
[OK] Highest usage of available connections: 9% (15/151)
[OK] Key buffer size / total MyISAM indexes: 384.0M/44.3M
[OK] Key buffer hit rate: 99.7% (16M cached / 53K reads)
[OK] Query cache efficiency: 100.0% (508M cached / 508M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 11K sorts)
[!!] Temporary tables created on disk: 42% (11K on disk / 26K total)
[OK] Thread cache hit rate: 99% (15 created / 5K connections)
[!!] Table cache hit rate: 1% (512 open / 31K opened)
[OK] Open file limit used: 9% (108/1K)
[OK] Table locks acquired immediately: 99% (96K immediate / 96K locks)
[OK] InnoDB buffer pool / data size: 384.0M/90.4M
[!!] InnoDB log waits: 1
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Increase table_cache gradually to avoid file descriptor limits
    Read this before increasing table_cache over 64: http://bit.ly/1mi7c4C
Variables to adjust:  
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    table_cache (> 512)
    innodb_log_buffer_size (>= 1M)

    Czy mogę liczyć na jakieś wskazówki ? Na co jeszcze zwrócić uwagę ? Acha. IO też jest w porządku podczas obciążenia procka, więc to nie wina dysków...

     

  9. Napisano · Raportuj odpowiedź

    autoryzację masz włączoną ? bo serwer niby działa poprawnie

    $ telnet 37.28.154.21 25
Trying 37.28.154.21...
Connected to 37.28.154.21.
Escape character is '^]'.
220 node1.d3elite.pl ESMTP Postfix (Debian/GNU)
ehlo test.pl
250-node1.d3elite.pl
250-PIPELINING
250-SIZE
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
mail from: <test@o2.pl>
250 2.1.0 Ok
rcpt to: <postmaster@d3elite.pl>
250 2.1.5 Ok
×