max_connections erhöhen

Lord_Icon

Member
Hi,

ich würde gern die maximale Verbindungen erhöhen.

Laut Reschere muß ich max_connections von 200 (default) auf Wunschwert erhöhen.

Nun habe ich schon in meine /etc/my.cnf nachgeschaut. Aber da gibt es keinen solchen Wert.

Wo finde ich diesen ?
Bzw. ist max_connections für mein Vorhaben denn überhaupt das richtige ?
 
Laut Reschere muß ich max_connections von 200 (default) auf Wunschwert erhöhen.
Default ist je nach Version 100 oder 151.

Nun habe ich schon in meine /etc/my.cnf nachgeschaut. Aber da gibt es keinen solchen Wert.
Dann schreib ihn rein.

Bzw. ist max_connections für mein Vorhaben denn überhaupt das richtige ?
Vielleicht. :rolleyes:

Manual: http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_max_connections
 
Wofür brauchst du denn die vielen Verbindungen?
Wenn das z.B. von einer stark besuchten Webseite kommt, würdest du es im Schlimmsten Fall mit dem Erhöhen der Verbindungen zusätzlich ausbremsen. Da hilft es meistens, persistente Verbindungen zur Datenbank aufbauen zu lassen, die nach Scriptende weiter bestehen bleiben und beim nächsten Aufruf wieder genutzt werden.
 
Ich habe ab und zu das Problem, das die SQL-Verbindung nicht mehr besteht.
Warte ich dann 1-2 Sekunden klappt dann alles wieder.

Da ich mittlerweile recht viele HP's auf dem Server habe, dachte ich, das diese zu viele Verbindungen gleichzeitig aufbauen und deshalb das Probem auftaucht.

Hab es nun erhöht und werde das mal beobachten, ob das Problem immer noch besteht.
 
Code:
echo "show global status like 'Max_used_connections'" |mysql -u root

Was gibt das aus?
Wurden denn alle 200 Verbindungen in der Vergangenheit wirklich ausgenutzt?

Zudem würde ich die Gesamtauslastung des Systemes zum Zeitpunkt der max. Verbindungen prüfen.
Letzendlich bedeuten mehr Verbindungen auch mehr Ressourcenverbrauch.
 
Code:
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 132   |
+----------------------+-------+
1 row in set (0.00 sec)
 
Also wurden die 200 Verbindungen noch nicht aufgebraucht.
Wie lange läuft die DB denn schon?

Code:
echo "show global status like 'Uptime'" |mysql -u root
 
Code:
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Uptime        | 7928  |
+---------------+-------+
1 row in set (0.01 sec)

Vorher stand es auf 100 (default) (Nicht wie vorher angenommen auf 150)
Hab es erstmal auf 250 gesetzt.

Hier mal den Status complet.

Code:
+-----------------------------------+----------+
| Variable_name                     | Value    |
+-----------------------------------+----------+
| Aborted_clients                   | 342      |
| Aborted_connects                  | 1        |
| Binlog_cache_disk_use             | 0        |
| Binlog_cache_use                  | 0        |
| Bytes_received                    | 180      |
| Bytes_sent                        | 461      |
| Com_admin_commands                | 0        |
| Com_alter_db                      | 0        |
| Com_alter_table                   | 0        |
| Com_analyze                       | 0        |
| Com_backup_table                  | 0        |
| Com_begin                         | 0        |
| Com_call_procedure                | 0        |
| Com_change_db                     | 0        |
| Com_change_master                 | 0        |
| Com_check                         | 0        |
| Com_checksum                      | 0        |
| Com_commit                        | 0        |
| Com_create_db                     | 0        |
| Com_create_function               | 0        |
| Com_create_index                  | 0        |
| Com_create_table                  | 0        |
| Com_create_user                   | 0        |
| Com_dealloc_sql                   | 0        |
| Com_delete                        | 0        |
| Com_delete_multi                  | 0        |
| Com_do                            | 0        |
| Com_drop_db                       | 0        |
| Com_drop_function                 | 0        |
| Com_drop_index                    | 0        |
| Com_drop_table                    | 0        |
| Com_drop_user                     | 0        |
| Com_execute_sql                   | 0        |
| Com_flush                         | 0        |
| Com_grant                         | 0        |
| Com_ha_close                      | 0        |
| Com_ha_open                       | 0        |
| Com_ha_read                       | 0        |
| Com_help                          | 0        |
| Com_insert                        | 0        |
| Com_insert_select                 | 0        |
| Com_kill                          | 0        |
| Com_load                          | 0        |
| Com_load_master_data              | 0        |
| Com_load_master_table             | 0        |
| Com_lock_tables                   | 0        |
| Com_optimize                      | 0        |
| Com_preload_keys                  | 0        |
| Com_prepare_sql                   | 0        |
| Com_purge                         | 0        |
| Com_purge_before_date             | 0        |
| Com_rename_table                  | 0        |
| Com_repair                        | 0        |
| Com_replace                       | 0        |
| Com_replace_select                | 0        |
| Com_reset                         | 0        |
| Com_restore_table                 | 0        |
| Com_revoke                        | 0        |
| Com_revoke_all                    | 0        |
| Com_rollback                      | 0        |
| Com_savepoint                     | 0        |
| Com_select                        | 1        |
| Com_set_option                    | 0        |
| Com_show_binlog_events            | 0        |
| Com_show_binlogs                  | 0        |
| Com_show_charsets                 | 0        |
| Com_show_collations               | 0        |
| Com_show_column_types             | 0        |
| Com_show_create_db                | 0        |
| Com_show_create_table             | 0        |
| Com_show_databases                | 0        |
| Com_show_errors                   | 0        |
| Com_show_fields                   | 0        |
| Com_show_grants                   | 0        |
| Com_show_innodb_status            | 0        |
| Com_show_keys                     | 0        |
| Com_show_logs                     | 0        |
| Com_show_master_status            | 0        |
| Com_show_ndb_status               | 0        |
| Com_show_new_master               | 0        |
| Com_show_open_tables              | 0        |
| Com_show_privileges               | 0        |
| Com_show_processlist              | 0        |
| Com_show_slave_hosts              | 0        |
| Com_show_slave_status             | 0        | 
| Com_show_status                   | 3        |
| Com_show_storage_engines          | 0        |
| Com_show_tables                   | 0        |
| Com_show_triggers                 | 0        |
| Com_show_variables                | 0        |
| Com_show_warnings                 | 0        |
| Com_slave_start                   | 0        |
| Com_slave_stop                    | 0        |
| Com_stmt_close                    | 0        |
| Com_stmt_execute                  | 0        |
| Com_stmt_fetch                    | 0        |
| Com_stmt_prepare                  | 0        |
| Com_stmt_reset                    | 0        |
| Com_stmt_send_long_data           | 0        |
| Com_truncate                      | 0        |
| Com_unlock_tables                 | 0        |
| Com_update                        | 0        |
| Com_update_multi                  | 0        |
| Com_xa_commit                     | 0        |
| Com_xa_end                        | 0        |
| Com_xa_prepare                    | 0        |
| Com_xa_recover                    | 0        |
| Com_xa_rollback                   | 0        |
| Com_xa_start                      | 0        |
| Compression                       | OFF      |
| Connections                       | 4284     |
| Created_tmp_disk_tables           | 0        |
| Created_tmp_files                 | 5        |
| Created_tmp_tables                | 2        |
| Delayed_errors                    | 0        |
| Delayed_insert_threads            | 0        |
| Delayed_writes                    | 0        |
| Flush_commands                    | 1        |
| Handler_commit                    | 0        |
| Handler_delete                    | 0        |
| Handler_discover                  | 0        |
| Handler_prepare                   | 0        |
| Handler_read_first                | 0        |
| Handler_read_key                  | 0        |
| Handler_read_next                 | 0        |
| Handler_read_prev                 | 0        |
| Handler_read_rnd                  | 0        |
| Handler_read_rnd_next             | 2        |
| Handler_rollback                  | 0        |
| Handler_savepoint                 | 0        |
| Handler_savepoint_rollback        | 0        |
| Handler_update                    | 0        |  
| Handler_write                     | 133      |
| Innodb_buffer_pool_pages_data     | 20       |
| Innodb_buffer_pool_pages_dirty    | 0        |
| Innodb_buffer_pool_pages_flushed  | 0        |
| Innodb_buffer_pool_pages_free     | 492      |
| Innodb_buffer_pool_pages_latched  | 0        |
| Innodb_buffer_pool_pages_misc     | 0        |
| Innodb_buffer_pool_pages_total    | 512      |
| Innodb_buffer_pool_read_ahead_rnd | 1        |
| Innodb_buffer_pool_read_ahead_seq | 0        |
| Innodb_buffer_pool_read_requests  | 324      |
| Innodb_buffer_pool_reads          | 13       |
| Innodb_buffer_pool_wait_free      | 0        |
| Innodb_buffer_pool_write_requests | 0        |
| Innodb_data_fsyncs                | 3        |
| Innodb_data_pending_fsyncs        | 0        |
| Innodb_data_pending_reads         | 0        |
| Innodb_data_pending_writes        | 0        |
| Innodb_data_read                  | 2510848  |
| Innodb_data_reads                 | 26       |
| Innodb_data_writes                | 3        |
| Innodb_data_written               | 1536     |
| Innodb_dblwr_pages_written        | 0        |
| Innodb_dblwr_writes               | 0        |
| Innodb_log_waits                  | 0        |
| Innodb_log_write_requests         | 0        |
| Innodb_log_writes                 | 1        |
| Innodb_os_log_fsyncs              | 3        |
| Innodb_os_log_pending_fsyncs      | 0        |
| Innodb_os_log_pending_writes      | 0        |
| Innodb_os_log_written             | 512      |
| Innodb_page_size                  | 16384    |
| Innodb_pages_created              | 0        |
| Innodb_pages_read                 | 20       |
| Innodb_pages_written              | 0        |
| Innodb_row_lock_current_waits     | 0        |
| Innodb_row_lock_time              | 0        |
| Innodb_row_lock_time_avg          | 0        |
| Innodb_row_lock_time_max          | 0        |
| Innodb_row_lock_waits             | 0        |
| Innodb_rows_deleted               | 0        |
| Innodb_rows_inserted              | 0        |
| Innodb_rows_read                  | 0        |
| Innodb_rows_updated               | 0        |
| Key_blocks_not_flushed            | 0        |
| Key_blocks_unused                 | 13301    |
| Key_blocks_used                   | 272      |
| Key_read_requests                 | 4070349  |
| Key_reads                         | 8174     |
| Key_write_requests                | 2504     |
| Key_writes                        | 375      |
| Last_query_cost                   | 0.000000 |
| Max_used_connections              | 132      |
| Not_flushed_delayed_rows          | 0        |
| Open_files                        | 127      |
| Open_streams                      | 0        |
| Open_tables                       | 64       |
| Opened_tables                     | 0        |
| Prepared_stmt_count               | 0        |
| Qcache_free_blocks                | 0        |
| Qcache_free_memory                | 0        |
| Qcache_hits                       | 0        |
| Qcache_inserts                    | 0        |
| Qcache_lowmem_prunes              | 0        |
| Qcache_not_cached                 | 0        |
| Qcache_queries_in_cache           | 0        |
| Qcache_total_blocks               | 0        |
| Questions                         | 225954   |
| Rpl_status                        | NULL     |
| Select_full_join                  | 0        |
| Select_full_range_join            | 0        |
| Select_range                      | 0        |
| Select_range_check                | 0        |
| Select_scan                       | 2        |
| Slave_open_temp_tables            | 0        |
| Slave_retried_transactions        | 0        |
| Slave_running                     | OFF      |
| Slow_launch_threads               | 0        |
| Slow_queries                      | 0        |
| Sort_merge_passes                 | 0        |
| Sort_range                        | 0        |
| Sort_rows                         | 0        |
| Sort_scan                         | 0        |
| Table_locks_immediate             | 259940   |
| Table_locks_waited                | 1        |
| Tc_log_max_pages_used             | 0        |
| Tc_log_page_size                  | 0        |
| Tc_log_page_waits                 | 0        |
| Threads_cached                    | 0        |
| Threads_connected                 | 23       |
| Threads_created                   | 4283     |
| Threads_running                   | 1        |
| Uptime                            | 7952     |
| Uptime_since_flush_status         | 7952     |
+-----------------------------------+----------+
226 rows in set (0.00 sec)
 
Das abortet Clients würde mich zum nachdenken anregen.

Da kann was nicht stimmen und das würde ich ggf. genau prüfen wer oder welches Script mit falschen Benutzerdaten versucht sich zu verbinden.
 
???
Es heißt doch "Aborted_clients"... also "Abgebrochene lokale Rechner".
Bzw. Abgebrochene Verbindungen von Clients

Also hat die Gegenseite die Verbindung abgebrochen oder ist so schnell wieder zurückgewechselt, das SQL nicht mehr geschlossen worden ist.

Und das kann durchaus hinhauen. Denn den Fehler, das ich eine weiße Seite bekomme, habe ich schon länger vernachlässigt. Wobei ich MYSQL zum Zeitpunkt des 1ten Postings neu gestartet habe. (wg. connections erhöhung)

Vermutlich ist diese Zahl noch weit aus höher. Schaue ich aber morgen nochmal
 
Das lässt sich auch online setzen.

set global max_connections=250;

Aber einfach nur die Connections hoch drehen, ist im übrigen keine Lösung.

-> Bei 130 max genutzten Verbindungen ohnehin nicht.

Achja und abortet Clients, Connections können sowohl vom Server als auch vom Client abgebrochen sein.

Wichtig ist hierbei die wahre Ursache heraus zu finden!
 
Achja und abortet Clients, Connections können sowohl vom Server als auch vom Client abgebrochen sein.

Wichtig ist hierbei die wahre Ursache heraus zu finden!

Das wird schwierig... auf den Server laufen auch HP's von meinen Bekannten/Kumpels. Wir haben uns einen großen Server gemietet und teilen uns die Kosten.

Aber ich hab mal MySQLTuner rübergeschickt... aber das werd ich in ein paar Tagen nochmal machen... weil mit 4h wird wohl kaum was zu analysieren sein.
Aber vllt. isses jetzt ja schon mal hilfreich.

Code:
 >>  MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: root
Please enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.67
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 171M (Tables: 4314)
[--] Data in InnoDB tables: 16K (Tables: 1)
[--] Data in MEMORY tables: 0B (Tables: 1)
[!!] Total fragmented tables: 279

-------- Performance Metrics -------------------------------------------------
[--] Up for: 4h 8m 49s (533K q [35.734 qps], 7K conn, TX: 445M, RX: 295M)
[--] Reads / Writes: 95% / 5%
[--] Total buffers: 42.0M global + 1.6M per thread (250 max threads)
[OK] Maximum possible memory usage: 448.2M (10% of installed RAM)
[OK] Slow queries: 0% (0/533K)
[OK] Highest usage of available connections: 52% (132/250)
[OK] Key buffer size / total MyISAM indexes: 16.0M/64.3M
[OK] Key buffer hit rate: 99.7% (7M cached / 18K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 42K sorts)
[!!] Joins performed without indexes: 3229
[OK] Temporary tables created on disk: 5% (1K on disk / 37K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 12K opened)
[OK] Open file limit used: 10% (127/1K)
[OK] Table locks acquired immediately: 99% (624K immediate / 624K locks)
[OK] InnoDB data size / buffer pool: 16.0K/8.0M

-------- 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
    Adjust your join queries to always utilize indexes
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    query_cache_size (>= 8M)
    join_buffer_size (> 128.0K, or always use indexes with joins)
    thread_cache_size (start at 4)
    table_cache (> 64)
 
Das sieht erstmal noch nicht dramatisch aus.

Ein 4 GB System und max. ca. 450 MB Speicherverbauch bei 250 Verbindungen.

Meiner Meinung nach können da nicht viele Daten vorhanden sein und die DB auch noch nicht wirklich optimiert.

[--] Total buffers: 42.0M global + 1.6M per thread (250 max threads)
[OK] Maximum possible memory usage: 448.2M (10% of installed RAM)
 
Wie gesagt... großes System.
Alles in allen habe ich ca. 120 vHost... ergo entsprechend viele HP's.
Mal kleine, die kaum Last verusachen... aber auch andere, wo Blogs/Forum/Browsergame drüber laufen.

Ich warte aber mal noch n paar Tage ab.
MYSQL war ja jetzt späten abend neu gestartet... da is noch nicht viel los. Übers WE wird es dann richtig rund gehen. Ich hoffe, das sich dann der Fehler besser herauskristallisiert.
 
Wie gross sind denn die Datenmengen?

Der Einsatz von InnoDB stat MyIsam könnte in punkto caching einiges an Performance bringen.

Zusätzlich könnte eine query-cache bei vielen statischen Daten und identischen Abfragen (hohe lesende Besucher auf einem Blog und wenig Änderungen) ebenfalls noch die performance verbessern. Damit liese sich die Dauer von Abfragen veringern und die damit ggf. notwendigen vielen Verbindungen vermeiden.


Aber eine DB entsprechend zu optimieren, ist eine Thema für sich und "langwierig" zumindest wenn man eine ideale Lösung für die eigene Umgebung finden will.

Einen verhältnismässig guten Thread und brauchbare Konfiguration für Hoster findest Du hier:
http://www.rootforum.org/forum/viewtopic.php?f=104&t=36343

siehe mal die letzten Beiträge hier genauer an.
 
Ich habe ab und zu das Problem, das die SQL-Verbindung nicht mehr besteht.
Bitte genauer definieren!!!
Aufgrund der fehlenden Fehlermeldung und ob es ein lokales Problem ist oder eine externe Connection, tappt der Thread mehr oder weniger im Dunkeln.

Zusätzlich solltest Du noch angeben wie hoch die MaxClients im Apache stehen. Das man z.B. mit 500 Apache-Clients 100 MySQL-Verbindungen voll bekommen kann ist wahrscheinlich klar. ;)
Auch die php.ini Einstellungen von mysql.allow_persistent, mysql.max_persistent, mysql.max_links sind in diesem Fall interessant.
Denn damit könnte man vor sich hin dümpelnde Verbindungen unterbinden.

Achja und abortet Clients, Connections können sowohl vom Server als auch vom Client abgebrochen sein.
Hust hust! Nein, immer nur Client-seitig.
Wenn der MySQL z.B. von extern zugänglich ist, ist das bereits eine ausreichende Erklärung.
Aber auch fcgi-Scripte oder mod_php ohne persistend-connections können diese Anzahl bei auftretenden Fehlern erhöhen.

Einen verhältnismässig guten Thread und brauchbare Konfiguration für Hoster findest Du hier:
http://www.rootforum.org/forum/viewtopic.php?f=104&t=36343
Die Angaben dort sind viel zu pauschal und auch fehlerhaft.
Z.B. wird table_cache deutlich erhöht ohne open_files_limit anzupassen.
Das bremst den MySQL eher aus als das es hilft.
Persönliche Meinung: Diese inzwischen 5 Jahre alte Anleitung sollte man eher nicht mehr betrachten.

Mit MySQLtuner oder tuning-primer wird man i.d.R. bereits auf den richtigen Pfad geleitet. Bei 4GB RAM kann man bei der Speichervergabe auch nicht mehr viel falsch machen.
Wenn die blockierenden Connections allerdings wegen Attacken gegen einen offenen MySQL-Port kommen, könnte man den Port einfach von 3306 auf z.B. 3307 verlegen.

huschi.
 
Bitte genauer definieren!!!
Aufgrund der fehlenden Fehlermeldung und ob es ein lokales Problem ist oder eine externe Connection, tappt der Thread mehr oder weniger im Dunkeln.
Also bis dato WAREN ein paar DB auch extern geschalten.
Habe diese jetzt erstmal deaktiviert weil z.Zt. unnötig.
Fraglich ist jetzt, ob ich jetzt auch alles richtig konfiguriert habe, sodass MYSQL tatsächlich nicht öffentlich ist.... aber dazu gibt es ja nmap.
Problem dabei ist aber, das ich dessen Einsatz nicht wirklich verstehe.
Führe ich nmap -v <domain> auf den Server direkt aus erhalte ich das:
Code:
Not shown: 990 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
110/tcp  open  pop3
143/tcp  open  imap
993/tcp  open  imaps
995/tcp  open  pop3s
3306/tcp open  mysql

Read data files from: /usr/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds
           Raw packets sent: 1000 (44.000KB) | Rcvd: 2010 (84.440KB)
Vermutlich wird hier nicht wirklich gescannt sondern eher die /usr/share/nmap/nmap-service zu rate gezogen.

Führe ich das ganze nochmal extern auf die gleiche domain durch, erhalte ich schon ganz andere Daten... + es dauert weit aus länger.
Code:
Not shown: 1687 filtered ports
PORT    STATE  SERVICE
21/tcp  open   ftp
22/tcp  open   ssh
25/tcp  open   smtp
80/tcp  open   http
110/tcp open   pop3
143/tcp open   imap
443/tcp closed https
465/tcp closed smtps
993/tcp open   imaps
995/tcp open   pop3s

Nmap finished: 1 IP address (1 host up) scanned in 66.769 seconds
               Raw packets sent: 5083 (223.650KB) | Rcvd: 20 (834B)

Theoretisch sollte mysql dicht sein (?).


Zusätzlich solltest Du noch angeben wie hoch die MaxClients im Apache stehen. Das man z.B. mit 500 Apache-Clients 100 MySQL-Verbindungen voll bekommen kann ist wahrscheinlich klar. ;)
Auch die php.ini Einstellungen von mysql.allow_persistent, mysql.max_persistent, mysql.max_links sind in diesem Fall interessant.
Denn damit könnte man vor sich hin dümpelnde Verbindungen unterbinden.
Code:
[B]Max Requests[/B] 	Per Child: 10000 - Keep Alive: on - Max Per Connection: 100
[B]Timeouts[/B] 	Connection: 300 - Keep-Alive: 15

[B]Loaded Modules[/B] 	core prefork http_core mod_so mod_actions mod_alias mod_auth_basic mod_authn_file mod_authz_host mod_authz_groupfile mod_authz_default mod_authz_user mod_authn_dbm mod_autoindex mod_cgi mod_dir mod_env mod_expires mod_include mod_log_config mod_mime mod_negotiation mod_setenvif mod_ssl mod_suexec mod_userdir mod_php5 mod_rewrite mod_vhost_alias mod_status mod_evasive20 mod_log_sql mod_log_sql_mysql
MOD: Bilder bitte immer als Anhang!
MaxClients habe ich glaube ich nicht aktiviert. Würde sogar soweit gehen wollen und behaupten, das ich hierfür garnicht das modul aktiviert habe.
Zumindest sagt phpinfo und http.conf nichts darüber aus.

Hoffe, das ich alle Variablen gepostet habe... aber wie man sieht, ist so gut wie alles noch auf default. Hat ja bisher auch alles wunderbar geklappt.



Wenn die blockierenden Connections allerdings wegen Attacken gegen einen offenen MySQL-Port kommen, könnte man den Port einfach von 3306 auf z.B. 3307 verlegen.
Hoffe, das MYSQL jetzt erstmal nicht mehr öffentlich ist.
Zusätzlich habe ich mal denyhost etwas senibilisiert.
BLOCK_SERVICE = ALL

Frage hierzu: Wie trenne ich denn 2 Dienste bei DENYHOST ?
Die Manuell sagt hierzu rein garnichts aus. Mit ; ?
BLOCK_SERVICE = sshd;mysql
 

Attachments

  • ab7dnhsi.jpg
    ab7dnhsi.jpg
    147.3 KB · Views: 186
Last edited by a moderator:
Hust hust! Nein, immer nur Client-seitig.
Wenn der MySQL z.B. von extern zugänglich ist, ist das bereits eine ausreichende Erklärung.
Aber auch fcgi-Scripte oder mod_php ohne persistend-connections können diese Anzahl bei auftretenden Fehlern erhöhen.
Wenn nun ein access Denied kommt, wer klemmt dann die Verbindung ab?
Richtig der Server, nachdem er dem Client die Begründung geliefert hat.


Die Anleitung im Rootforum ist zwar durchaus alt, die dort gefundene Konfiguration für den typischen Rootserver absolut ausreichend.
Da wo man nicht weiss, was auf einen zukommt und welche Anforderung man wirklich erfüllen muss, muss man immer einen Spagat der im gesamten gewählten Einstellung finden, sodass alle Komponenten im mix gut laufen.
 
Wenn nun ein access Denied kommt, wer klemmt dann die Verbindung ab?
Richtig der Server, nachdem er dem Client die Begründung geliefert hat.

Hmm... da werfe ich mal wieder meine Bedenken ein.
Wenn der Zugriff auf die Seite eh schon verboten ist... dann ist ja auch kein Zugriff auf ein Script erfolgt, die eine DB Verbindung herstellen hätte können.

Sprich = dürfte ich in der SQL-Statistik garnicht sehen.
 
Einfacher geht es in der my.cnf.

-> skip-networking

Danach mysql neu starten.
Dieser ist dann nur noch über Socket zu erreichen.
 
Back
Top