☰

网站瘫痪，无法通过 Ubuntu 14.04 x64 Digitalocean 上的 SSH/Putty 登录

tag-icon • tag-icon lamp magento cloud-hosting
网站瘫痪，无法通过 Ubuntu 14.04 x64 Digitalocean 上的 SSH/Putty 登录

我在 degitalocean.com 上有一个 Magento 网站，我无法通过 SSH 或 SFTP 登录。几乎每隔一天我都会遇到这个问题，我必须通过 digitalocean 帐户重新启动我的 droplet 才能使网站正常运行。几天前它出现 MYSQL 连接错误，我通过将 droplet RAM 增加到 2GB 并创建 SWAP 文件解决了这个问题。

有人能为这个问题提出解决方案吗？如果您想查看任何代码文件，请告诉我。

我从 error.log 中添加了几行，请看看这是否有帮助

 150808 10:18:38 [Note] Plugin 'FEDERATED' is disabled.
 150808 10:18:38 InnoDB: The InnoDB memory heap is disabled
 150808 10:18:38 InnoDB: Mutexes and rw_locks use GCC atomic builtins
 150808 10:18:38 InnoDB: Compressed tables use zlib 1.2.8
 150808 10:18:38 InnoDB: Using Linux native AIO
 150808 10:18:38 InnoDB: Initializing buffer pool, size = 128.0M
150808 10:18:38 InnoDB: Completed initialization of buffer pool
150808 10:18:47 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
150808 10:18:47  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
150808 10:18:49  InnoDB: Waiting for the background threads to start
150808 10:18:50 InnoDB: 5.5.38 started; log sequence number 976719446
150808 10:18:50 [Note] Server hostname (bind-address): '178.**.42.108'; port: 3306
150808 10:18:50 [Note]   - '178.**.42.108' resolves to '178.**.42.108';
150808 10:18:50 [Note] Server socket created on IP: '178.**.42.108'.
150808 10:19:01 [Note] Event Scheduler: Loaded 0 events
150808 10:19:01 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.38-0ubuntu0.14.04.1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)
150808 10:21:00 [Warning] IP address '221.211.62.106' could not be resolved: Name or service not known
150808 11:17:09 [Warning] IP address '115.238.245.12' could not be resolved: Name or service not known

我的cnf

#
# The MySQL database server configuration file.
#
# You can copy this to one of:
# - "/etc/mysql/my.cnf" to set global options,
# - "~/.my.cnf" to set user-specific options.
# 
# One can use all long options that the program supports.
# Run program with --help to get a list of available options and with
# --print-defaults to see which it would actually understand and use.
#
# For explanations see
# http://dev.mysql.com/doc/mysql/en/server-system-variables.html

# This will be passed to all mysql clients
# It has been reported that passwords should be enclosed with ticks/quotes
# escpecially if they contain "#" chars...
# Remember to edit /etc/mysql/debian.cnf when changing the socket location.
[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

# Here is entries for some specific programs
# The following values assume you have at least 32M ram

# This was formally known as [safe_mysqld]. Both versions are currently parsed.
[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
#
# * Basic Settings
#
user        = mysql
performance_schema             = off
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address        = 127.0.0.1
#
# * Fine Tuning
#
key_buffer      = 32M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover-options  = BACKUP
#max_connections        = 100
#table_cache            = 128
#thread_concurrency     = 10
#
# * Query Cache Configuration
#
query_cache_limit   = 1M
query_cache_size        = 32M
#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# As of 5.1 you can enable the log at runtime!
#general_log_file        = /var/log/mysql/mysql.log
#general_log             = 1
#
# Error log - should be very few entries.
#
log_error = /var/log/mysql/error.log
#
# Here you can see queries with especially long duration
#log_slow_queries   = /var/log/mysql/mysql-slow.log
#long_query_time = 2
#log-queries-not-using-indexes
#
# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id      = 1
#log_bin            = /var/log/mysql/mysql-bin.log
expire_logs_days    = 10
max_binlog_size         = 100M
#binlog_do_db       = include_database_name
#binlog_ignore_db   = include_database_name
#
# * InnoDB
#
# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
#
# * Security Features
#
# Read the manual, too, if you want chroot!
# chroot = /var/lib/mysql/
#
# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".
#
# ssl-ca=/etc/mysql/cacert.pem
# ssl-cert=/etc/mysql/server-cert.pem
# ssl-key=/etc/mysql/server-key.pem



[mysqldump]
quick
quote-names
max_allowed_packet  = 256M

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
socket      = /var/run/mysqld/mysqld.sock

[isamchk]
key_buffer      = 256M

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/

答案1

Digital Ocean 提供从控制面板访问控制台的功能。系统停机时使用该功能登录并收集信息，获得信息后使用该功能决定下一步该怎么做。其他一切都是猜测，根据您提供的信息，我猜是英仙座流星雨。

采用结构化和有条理的方法比四处乱窜要好得多。

我个人认为科学的方法（其他人称之为有些不同) 是系统管理工具包中诊断问题时可以使用的一个非常好的工具。

  1. 您真正想要解决的问题是什么？

服务停止响应。

  1. 现在我们知道了要解决的实际问题，我们有了一些方向。让我们收集一些信息来帮助我们找到解决方案。

    • 问题是否与时间有关？它是定期发生还是随机发生。
    • 检查您的日志，检查所有日志，而不仅仅是特定服务的日志，因为其他原因可能会导致问题。日志条目通常有时间戳，这是为了帮助您关联多个应用程序和服务之间的事件 - 使用它们。如有必要，也可以增加日志详细程度。
    • 观察你的系统在做什么。使用 top、vmstat、iostat、sar、ps、tcpdump 等工具，甚至全面的工具监控系统。

  2. 分析您收集到的信息。当服务停止响应时，系统上究竟发生了什么？系统资源的状态如何？

  3. 采取适当的措施进行补救。希望您能清楚地知道发生了什么，内存不足，OOM 杀手开始发挥作用，您的交换活动太高，您的运行队列太长，您受到 iobound 等。如果情况不明显，那么您可能没有收集正确的数据 - 您知道该怎么做，请返回 2。

  4. 监控4.处引入的变更。

  5. 这些变化解决了问题吗？是好转了吗？还是恶化了？没有区别吗？接下来该怎么做取决于你发现了什么。你可能需要回到 2. 并收集更多相关数据，或者 3. 重新分析你拥有的数据，或者 4. 因为你已经确定了许多潜在的解决方案。

  6. 记录您的发现和所做的更改。

  7. 回到床上 / 下班回家 / 去酒吧。

答案2

我同意上述观点。采取有条不紊的方法来解决这个问题，乱挥动翅膀通常没有用。

SSH 守护进程似乎停止了，因此请通过主机控制面板进入具有控制台访问权限的机器（如果它们不提供控制台访问权限，则移动主机）并重新启动服务。现在查看日志，使用 top 或 iotop 等工具监控系统性能，并尝试找出 SSH 停止前机器发生了什么。

记录您所做的任何更改以及最终采取的修复措施非常重要。

汤姆

相关内容