文章目录
- Dubbo服务启动依赖检查
- Dubbo负载均衡策略
- Dubbo线程模型（结合Linux线程数限制配置的实战分享）
- 实战经验分享（ ** 属用性能调优**）：
Dubbo服务启动依赖检查
Dubbo 官方文档:
用户指南 >> 示例 >> 启动时检查
举个?：假如b服务依赖于a服务，那么a服务启动之前b服务是启动不了的，如果a服务关掉了，b服务是不能启动的。默认情况下是检查的，只有设置了check=“false”，的时候，b在启动的时候就不会做这个检查，也就不会报错了。
注意上面这段话：
如果你的spring容器是懒加载的（就是必须等到spring启动完成之后，服务才能正常启动），或者通过api编程延迟引用服务，请关闭check，否则服务临时不可用时，会抛出异常，拿到null引用，如果check=false，总是会返回引用，当服务恢复时，能自动连上。
Dubbo负载均衡策略
Dubbo 官方文档:
用户指南 >> 示例 >> 负载均衡
默认是随机调用策略，通过权重
在dubbo的管理平台有关于权重的展示和设置
默认值是一百。
如图所示，能够在管控台调节权重和负载均衡，在管控台进行设置，相当于在代码中的配置文件中设置了locdbalance=“xxx”
所以一般不再代码中写死配置，一般默认的即可，如果需要配置的在管控台进行设置就好了。
Dubbo线程模型（结合Linux线程数限制配置的实战分享）
Dubbo 官方文档:
用户指南 >> 示例 >> 线程模型
dubbo中的dispatcher默认是all
配置标签：
dubbo:provider/
dubbo:protocol/
例子：
<dubbo:protocol name=“dubbo” port = “20818”>
//当protocolconfig和serviceconfig没有配置时，采用此缺省值。
<dubbo:provider timeout=“10000” threadpool=“fixed” accept=“1000”>
accepts允许介入的数量
实战经验分享（ 属用性能调优）：
Linux 用户线程数限制导致的 ** java.lang.OutOfMemoryError: unable to create new native thread **异常
默认用户可创建的最大线程数是1024个，
centos配置：
#vi /etc/security/limits.d/90-nproc.conf
#Default limit for number of user's processes to prevent
#accidental fork bombs.
#See rhbz
#432903 for reasoning.
root soft nproc unlimited //root用户是不做限制的
* soft nproc 20480 //普通用户从1024修改为20480如果dubbo部署的比较多，调用的比较频繁，很快就会被用光。
调整时要注意：
1、 尽量不要使用 root 用户来部署应用程序，避免资源耗尽后无法登录操作系统。 只能通过硬重启强行关机。
2、 普通用户线程数量限制要看可用物理内存容量来配置。
配置最大线程数计算方式：
default_nproc = total_memory/128K;//物理内存/128k (接近)
$ cat /proc/meminfo |grep MemTotal //看到自己物理机的内存
$ echo "5993104 / 128"| bc //计算出允许创建的最大线程数
//使用上面的方式计算只是大概的方式
//通过下面的命令直接显示真正的具体可创建线程数是多少。
//这两个值是很接近的，实际情况中，直接运行下面的命令即可。
$ ulimit -u
ulimit -a # 显示目前资源限制的设定
ulimit -u # 用户最多可开启的程序数目
重启，使之生效：# reboot
