Suzf Blog

许久之前，再次打开在本地 VM 创建的 Couchbase 有些异常 服务无法正常运行 查看日志，如下：

# /opt/couchbase/var/lib/couchbase/logs/info.log
[ns_server:warn,2016-08-15T13:47:59.536+08:00,[email protected]:dist_manager<0.129.0>:dist_manager:wait_for_address:121]Cannot listen on address `cb1.suzf.net`: eaddrnotavail
[ns_server:info,2016-08-15T13:47:59.536+08:00,[email protected]:dist_manager<0.129.0>:dist_manager:wait_for_address:125]Configured address `cb1.suzf.net` seems to be invalid. Giving OS a chance to bring it up.
[ns_server:error,2016-08-15T13:48:00.537+08:00,[email protected]:dist_manager<0.129.0>:dist_manager:init:178]Configured address `cb1.suzf.net` seems to be invalid. Will refuse to start for safety reasons.

看起来是说主机名称  cb.suzf.net  无效，以至于服务 无法正常启动。 O 想起来了， 曾经修改过 /etc/hosts 记录

#grep cb /etc/hosts
172.16.9.10     cb1.suzf.net
172.16.9.20     cb2.suzf.net

而当前的IP为

#ifconfig eth1|grep 'inet addr'
          inet addr:172.16.9.11  Bcast:172.16.9.255  Mask:255.255.255.0

下面来更正 hosts 记录

#grep cb /etc/hosts
172.16.9.11     cb1.suzf.net
172.16.9.20     cb2.suzf.net

It worked.

There are several ways you can provide hostnames:

• When installing a Couchbase Server on a machine.
• When adding a node to an existing cluster for an online upgrade.
• Using a REST API call.

Hostname Errors

Provide the hostname and port for the node and administrative credentials for the cluster. The value you provide for hostname must be a valid hostname for the node. Possible errors that can occur:

• Could not resolve the host name. The host name you provide as a parameter does not resolve to a IP address.
• Could not listen. The host name resolves to an IP address, but no network connection exists for the address.
• Could not rename the node because name was fixed at server start-up.
• Could not save address after rename.
• Requested name host name is not allowed. Invalid host name provided.
• Renaming is disallowed for nodes that are already part of a cluster.

节选自： http://developer.couchbase.com/documentation/server/4.1/install/hostnames.html

今天对系统进行更新大更新了一百多个包，但唯独一个包安装失败。
错误信息如下： error: unpacking of archive failed on file /etc/inittab: cpio: renamecpio
错误 从字面上上来看应该是拷贝/替换文件错误 ， 原因可能是权限控制

[10:31:12][[email protected] ~]#yum upgrade -y
Loaded plugins: fastestmirror
Setting up Upgrade Process
...

Running Transaction
Updating : initscripts-9.03.49-1.el6.centos.x86_64 1/2
Error unpacking rpm package initscripts-9.03.49-1.el6.centos.x86_64
error: unpacking of archive failed on file /etc/inittab: cpio: rename
Verifying : initscripts-9.03.49-1.el6.centos.x86_64 1/2
initscripts-9.03.46-1.el6.centos.1.x86_64 was supposed to be removed but is not!
Verifying : initscripts-9.03.46-1.el6.centos.1.x86_64 2/2

Failed:
initscripts.x86_64 0:9.03.46-1.el6.centos.1 initscripts.x86_64 0:9.03.49-1.el6.centos

Complete!

所以错误应该出现在 /etc/inittab 以至于更新文件无法更改
可能是不可改变的属性已经设置在这个文件之上，让我们先来查看一下。

[10:32:22][[email protected] ~]#lsattr /etc/inittab
----i---------- /etc/inittab

让我们删除这个属性
[10:32:55][[email protected] ~]#chattr -i /etc/inittab

让我们再来执行以下更新 看看问题是否解决
[10:33:07][[email protected] ~]#yum upgrade -y
Loaded plugins: fastestmirror
Setting up Upgrade Process
...

Downloading Packages:
initscripts-9.03.49-1.el6.centos.x86_64.rpm | 945 kB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : initscripts-9.03.49-1.el6.centos.x86_64 1/2
warning: /etc/sysctl.conf created as /etc/sysctl.conf.rpmnew
Cleanup : initscripts-9.03.46-1.el6.centos.1.x86_64 2/2
Verifying : initscripts-9.03.49-1.el6.centos.x86_64 1/2
Verifying : initscripts-9.03.46-1.el6.centos.1.x86_64 2/2

Updated:
initscripts.x86_64 0:9.03.49-1.el6.centos

Complete!

至此，问题解决。

原文：How To Ask Questions The Smart Way
作者：Eric Steven Raymond, Rick Moen
翻译：王刚
时间：2010年9月28日

如果你想复制、镜像、翻译或引用本文，请参阅我的复制协议。
弃权申明

许多项目的网站在如何取得帮助的部分链接了本文，这没有关系，也正是我们想要的。但如果你是该项目生成此链接的网管，请在链接附近显著位置注明：我们不提供该项目的服务支持！

我们已经领教了没有此说明带来的痛苦，我们将不停地被一些白痴纠缠，他们认为既然我们发布了本文，那么我们就有责任解决世上所有的技术问题。

如果你是因为需要帮助正在阅读本文，然后就带着可以直接从作者那取得帮助的印象离开，那么你就不幸成了我们所说的白痴之一。 别向我们提问，我们不会理睬的。 我们只是在这教你如何从那些真正懂得你软硬件问题的人那里取得帮助，但 99.9％ 的时间我们不会是那些人。除非你非常地确定本文的作者是你遇到问题方面的专家，请不要打搅，这样大家都更开心一点。

引言

前几日 查看自己的 VPS 主机 返现 有报错信息如下：
kernel: TCP: time wait bucket table overflow
kernel: TCP: time wait bucket table overflow
kernel: TCP: time wait bucket table overflow
（TCP:时间等待桶表）

根据报错提示，需要更改net.ipv4.tcp_max_tw_buckets这个内核参数。这个参数是系统同时保持timewait套接字的最大数量。如果超过这个数字，time-wait套接字将立刻被清除并打印警告信息。这个限制仅仅是为了防止简单的 DoS攻击，你绝对不能过分依靠它或者人为地减小这个值，如果网络实际需要大于缺省值，更应该增加这个值(如果增加了内存之后)。

解决方法：增大 tcp_max_tw_buckets的值，并不是这个值越小越好，我看了我系统中TIME_WAIT 大部是由php-fpm产生的，是属于正常的现象。
系统在同时所处理的最大timewait sockets 数目。如果超过此数的话﹐time-wait socket 会被立即砍除并且显示警告信息。之所以要设定这个限制﹐纯粹为了抵御那些简单的 DoS 攻击﹐千万不要人为的降低这个限制﹐不过﹐如果网络条件需要比默认值更多﹐则可以提高它(或许还要增加内存)。

netstat -an | grep 9000 | awk '{print $6}' | sort | uniq -c | sort -rn
netstat -an | grep 80 | awk '{print $6}' | sort | uniq -c | sort -rn

排查步骤：

1. 查看服务器网络连接情况；

# netstat -pant |awk '/^tcp/ {++state[$6]} END {for(key in state) printf("%-10s\t%d\n",key,state[key]) }'
TIME_WAIT 6798
CLOSE_WAIT 1
ESTABLISHED 592
SYN_RECV 69
CLOSING 39
LAST_ACK 19
LISTEN 107

2.查看内核参数
#sysctl -a | grep net.ipv4.tcp_max_tw_buckets
net.ipv4.tcp_max_tw_buckets = 8192

改为：net.ipv4.tcp_max_tw_buckets = 10000

3.使更改的内核参数生效
sysctl -p

4. 再次查看服务器网络连接情况；

# netstat -pant |awk '/^tcp/ {++state[$6]} END {for(key in state) printf("%-10s\t%d\n",key,state[key]) }'
TIME_WAIT 6644
...

5.再看/var/log/messages和dmesg的信息，已经不再报错了
看来net.ipv4.tcp_max_tw_buckets=10000暂时是够用了

6.原因

服务器的TCP连接数，超出了内核定义最大数。

 

前不久定制了一个Sanfor的模板，后发现 发现内存图形呈现的数据太不靠谱了。和真是数据相差近千倍。

使用snmpwalk 抓取数据后发现单位是kb ， 靠懵了和 交换、路由的单位不太一样

查看了一下官方手册 ，在 item 有一个选项是 Use custom multiplier 可以转换单位

https://www.zabbix.com/documentation/2.0/manual/config/items/item