![](https://img-blog.csdnimg.cn/20201014180756925.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
性能优化
文章平均质量分 86
无心六神通
金融科技系统架构师
展开
-
操作系统内核-TCP-高并发-调优实战-演示-三次握手
操作系统内核-TCP-高并发-调优实战-演示-三次握手原创 2024-07-27 11:37:26 · 182 阅读 · 0 评论 -
linux修改文件句柄数量
ulimit 命令身是分软限制和硬限制,加-H就是硬限制,加-S就是软限制。硬限制就是实际的限制,而软限制是警告限制,它只会给出警告。假如,我们设置进程打开的文件句柄数是1024 ,但是系统总线制才500,所以所有进程最多能打开文件句柄数量500。文件句柄限制,就是规定的单个进程能够打开的最大文件句柄数量(Socket连接也算在里面,默认大小1024)其实上面的修改都是对一个进程打开的文件句柄数量的限制,我们还需要设置系统的总限制才可以。liunx中文件句柄有两种,一种是用户级的,一种是系统级的。原创 2024-07-21 09:53:16 · 407 阅读 · 0 评论 -
在 Linux 中,如何确定 optmem_max 的最佳值?
大多数发行版都考虑到了普通用户,而大多数普通用户,即使使用 Linux/Unix 作为服务器,也没有一个服务器群,它们之间有光纤 channel ,或者不需要 GB 的 IPC 传输的服务器进程.我对内核进行了 grep,但我找不到将 optmem_max 的默认值设置为 20480 的痕迹,这是我们系统上的默认值。20KB 的缓冲区对于“大多数”来说已经足够大了,它最大限度地减少了默认情况下所需的内核内存,而且配置起来也很容易,如果需要的话可以这样做。此外,我真的不明白 optmem_max 是什么。原创 2024-07-21 09:35:50 · 679 阅读 · 0 评论 -
Redisson-百万并发-单机27万QPS-调优实战
Redisson-百万并发-单机23万QPS-调优实战原创 2024-07-19 17:34:47 · 1369 阅读 · 0 评论 -
Linux 性能调优之网络内核参数优化
因此,结果是 1,815,250 字节。硬件层,物理层将数据的01转换为电压和脉冲光传输给物理的传输介质,相互直连的设备通过MAC(Media Access Control,介质访问控制)实现传输。传输层即进行建立连接或者断开连接,在两个主机之间创建逻辑上的通信连接,确保数据是否到达,没到达重发,保证数据的可靠性,涉及到的协议包括 TCP,UDP,DCDC。数据的流向整体是一个出栈入栈的过程,用应用层开始,包装数据,化整为零,分段传输,然后到物理层为信号传输,这是进栈,到达目标IP,在通过。原创 2024-07-17 23:39:53 · 515 阅读 · 0 评论 -
Linux系统内核参数优化
在工作中,平常我们使用官方镜像安装的Linux系统(非自定制化的)系统内核考虑的是最通用的场景,通常设定都偏向稳定保守,比较典型的代表如红帽系列的RHEL、CentOS等。而在正式的生成环境使用中,服务器的CPU、内存等硬件配置都比较高,而安装系统时默认的系统内核参数设定并不符合用于支持高并发访问的业务服务器,因此我们需要根据实际的业务特性来对系统的默认内核参数设定加以优化,以便能充分发挥服务器的硬件计算处理能力,提高资源利用率的同时也给企业节省IT设备资源成本。原创 2024-07-17 22:53:57 · 142 阅读 · 0 评论 -
Why would “TCP Full Window” happen?
0我明白,“TCP Full Window”表示发送方发送的数据比多?但为什么会发生这种情况呢?发送方不应该只是能够发送?还是因为wireshark看到更多的数据在发送端排队?但是wireshark是怎么知道的呢?发送缓冲区?原创 2024-07-17 21:57:02 · 562 阅读 · 0 评论 -
Dubbo3-高并发-性能优化-实践-踩坑-生产环境慎用tri协议
由于本文测的是端到端的全过程响应延时,包含了发送延时、传输延迟、接收延迟、响应延迟等全过程延迟,所以用6502 Kbits 作为缓冲区的默认值配置即可。带宽时延积 = 带宽*时延 = 1.95 Gbits/sec * 3.18ms = 6502 Kbits。如果不进行调优,最大缓冲区只有 87380 字节。整体上限页数计算,按1024个连接计算。tcpdump出现 滑动窗口溢出的提示。客户端、服务端都是同一虚拟机规格。出现大量请求报错,程序卡死。原创 2024-07-17 19:34:41 · 640 阅读 · 0 评论 -
tcp(7) — Linux Programmer‘s Manual
linux tcp编程手册原创 2024-07-15 11:42:54 · 807 阅读 · 0 评论 -
高性能网络编程7–tcp连接的内存使用
当服务器的并发TCP连接数以十万计时,我们就会对一个TCP连接在操作系统内核上消耗的内存多少感兴趣。socket编程方法提供了SO_SNDBUF、SO_RCVBUF这样的接口来设置连接的读写缓存,linux上还提供了以下系统级的配置来整体设置服务器上的TCP内存使用,但这些配置看名字却有些互相冲突、概念模糊的感觉,如下(sysctl -a命令可以查看这些配置):代码语言:javascript复制net.ipv4.tcp_rmem = 8192 87380 16777216 net.ipv4原创 2024-07-15 19:18:00 · 967 阅读 · 0 评论 -
linux 关闭nagle算法
总的来说,关闭Nagle算法在某些特定的网络传输场景下是非常有必要的,可以提高数据传输的实时性和效率。比如在一些实时性要求较高的网络传输场景中,延迟会带来很大的影响,此时关闭Nagle算法可以减少延迟,提高数据传输的实时性。另外,在一些大文件传输或者需要高速传输的场景中,关闭Nagle算法也可以提高数据传输的效率,加快传输速度。Nagle算法是一种用于减少网络传输中的数据包数目的算法,它会将小的数据包合并成一个更大的数据包再进行传输,以减少网络传输中的数据包数量,从而提高网络传输的效率。原创 2024-06-15 21:45:55 · 403 阅读 · 0 评论 -
单线程的Redis为什么能支持10w+的QPS?
这个命令的原理就是redis在内部执行了scan命令,遍历实例中所有的key,然后正对key的类型,分别执行strlen,llen,hlen,scard,zcard命令,来获取string类型的长度,容器类型(list,hash,set,zset)的元素个数。,Redis中保存的键值对是保存在一个字典中的(和Java中的HashMap类似,也是通过数组+链表的方式实现的),key的类型都是string,value的类型可以是string,set,list等。我们经常听到Redis是一个单线程程序。原创 2024-06-13 11:04:50 · 556 阅读 · 0 评论 -
高并发情况下backlog过低出现的问题
按照TCP/IP详解卷二的说法,如果listen的那个端点的队列满了(已经完成三次握手的队列,其大小由backlog确定),那么就不回复syn。但是,有个问题,如果多个syn同时到达,那么即使这时候队列未满,也可能接受了这些syn的一部分后队列就满了,那么linux系统如何处理——是否会存在有些链接三次握手完成,但是放不进队列里。之所以设置了timeout,是为了拿到hang住的端口号,测试时可以不设置timeout,然后在没有新的输出时,threadDump,可以看到有多个链接hang在read那里。原创 2024-06-13 11:02:58 · 248 阅读 · 0 评论 -
Centos内核参数优化(大并发)
异步I/o的技术就是使用AIO。如果考虑性能,poll()也是不合适的,尽管它可以支持较高的tcp并发数,但是由于其采用“轮询”机制,当并发数较高时,其运行效率相当低,并可能存在I/O事件分派不均,导致部分TCP连接上的I/O出现“饥饿”现象。2.2 内核的通常值是180秒,你可以按这个设置,但要记住的是,即使你的机器是一个轻载的WEB服务器,也有因为大量的死套接字而内存溢出的风险,FIN-WAIT-2的危险性比FIN-WAIT-1要小,因为它最多只能吃掉1.5K内存,但是它们的生存期长些。原创 2024-06-13 11:01:21 · 488 阅读 · 0 评论 -
性能分析之TCP全连接队列占满问题分析及优化过程
这时候,我们一定要记住,当出现请求事务大量失败的时候,一定要先看以下具体的错误信息,在继续往下面分析,而不是进行盲目的猜测,这里要提一下高楼老师经常强调的证据链,一定要根据详细的错误信息指向进行下一步分析,不能根据猜测进而通过修改一些参数,或者增加系统资源来解决问题。的值也变得很大,但是仍小于 5000,这也说明之前的 50 的确太小,导致全连接队列被占满,最终影响系统性能,出现大量请求失败,到此,由 TCP 连接队列满导致的问题解决。,严重影响系统的处理能力。为了快速的验证是写日志导致的,原创 2024-06-13 11:00:13 · 610 阅读 · 0 评论 -
TCP经典异常问题探讨与解决
skb在ip层这时候NAT刚完成第一次port(修改dport 1112为dport 80),然后进入了early demux机制,此时的4元组是[saddr:12345 -> daddr:80],所以这时候匹配上了第一条流的sk,但是系统并不知情有问题了,紧接着NAT第二次改变skb的port,变为[saddr:1112 -> daddr:80],这个也是后续TCP层延续使用的,虽然这个4元组信息是对的,但是已经没有用了,因为early demux阶段已经获取、保存socket了。出现问题的情景如下图。原创 2024-06-11 21:28:24 · 862 阅读 · 0 评论 -
为高吞吐量调优 TCP 连接
在 Red Hat Enterprise Linux 上调优与 TCP 相关的设置以提高吞吐量、缩短延迟或防止诸如数据包丢失等问题。原创 2024-06-11 08:42:08 · 817 阅读 · 0 评论 -
高并发linux内核参数调优
定义了系统中每一个端口最大的监听队列的长度,这是个全局的参数,默认值为128.限制了每个端口接收新tcp连接侦听队列的大小。对于一个TCP连接,Server与Client需要通过三次握手来建立网络连接.当三次握手成功后, 我们可以看到端口的状态由LISTEN转变为ESTABLISHED,接着这条链路上就可以开始传送数据了.每一个处于监听(Listen)状态的端口,都有自己的监听队列.监听队列的长度,与如下两方面有关: - somaxconn参数. - 使用该端口的程序中listen()函数.原创 2024-06-11 00:14:15 · 1133 阅读 · 0 评论 -
Spring Boot中的Jetty、Tomcat与Undertow:性能对比与Undertow线程池配置
在Spring Boot应用中,选择合适的Web服务器是至关重要的。常见的Web服务器有Jetty、Tomcat和Undertow。它们各自具有不同的特点和优势,下面将进行详细的比较。原创 2024-06-10 23:46:34 · 568 阅读 · 0 评论 -
Linux上TCP的几个内核参数调优
Linux作为一个强大的操作系统,提供了一系列内核参数供我们进行调优。光TCP的调优参数就有50多个。在和线上问题斗智斗勇的过程中,笔者积累了一些在内网环境应该进行调优的参数。在此分享出来,希望对大家有所帮助。原创 2024-06-10 23:26:44 · 858 阅读 · 0 评论 -
The ip_local_port_range parameters
您将在该文件的参数中看到两个数字:第一个数字是服务器上允许TCP和UDP流量的第一个本地端口,第二个是最后一个本地端口。对于高使用率的系统,您可以将其默认参数更改为32768-61000 -first-last。将上述命令添加到/etc/rc.d/rc.文件中本地脚本文件,下次重新启动系统时,您不必再输入它。原创 2024-06-10 22:58:15 · 262 阅读 · 0 评论 -
干货!超级详细的Linux抓包工具tcpdump详解!
后面跟的 protocol 要求就没有那么严格,它可以是任意词,只要 tcpdump 的 IP 报文头部里的 protocol 字段为 就能匹配上。当你在使用多个过滤器进行组合时,有可能需要用到括号,而括号在 shell 中是特殊符号,因为你需要使用引号将其包含。官方文档手册:https://www.tcpdump.org/manpages/tcpdump.1.html。后面跟的 的关键词是固定的,只能是。根据 tcpflags 进行过滤。基于协议进行过滤:proto。基于端口进行过滤:port。原创 2024-06-10 19:32:25 · 922 阅读 · 0 评论 -
Linux-TCP 出现 RST 的几种情况
问题就出在“我不接受数据” 上,如果此时客户端还往服务器发送数据,服务器内核接收到数据,但是发现此时Socket已经close了,则会返回“RST”标志给客户端。然后是客户端和服务器统一使用TCP长连接:客户端使用TCP长连接很容易配置(直接设置HttpClient就好),而服务器配置长连接就比较麻烦了,就拿tomcat来说,需要设置tomcat的maxKeepAliveRequests、connectionTimeout等参数。rst 前第一个消息write 是成功的,而第二条写才会告诉你连接被重置,原创 2024-06-10 19:24:46 · 903 阅读 · 0 评论 -
Jmeter运行报错software caused connection abort:recv failed
接下来调用InputStream的in.read(header, 0, 14);如果available()的返回值为0,说明没有响应数据,可能是对方已经断开连接,另外值得注意的是available()返回的值是非堵塞的,可以被多个线程访问。如果客户端在服务端关闭连接后,没有释放连接,继续试图发送请求和接收响应.总结产生原因,在服务端/客户端单方面关闭连接的情况下,另一方依然以为。客户端和服务端建立tcp的短连接,每次客户端发送一次请求,是由于程序编写的问题,而不是网络的问题引起的.原创 2024-06-10 14:16:24 · 628 阅读 · 0 评论 -
Linux Network (TCP) 性能调优 - Sysctl
在本文中,我们将讨论一些影响网络性能的sysctl参数。在深入讨论细节之前,我们首先看一下使用sysctl可以修改的一些内容。NFSProcesses可以通过运行下面的命令来找到所有sysctl参数的完整列表。我们将讨论sysctl中与网络相关的交换机,这些交换机的修改可以大大提高网络的速度。大多数Linux用户都知道这样一个事实:无论您在sysctl中修改什么,它最终都会修改/proc目录中的某个文件。在运行的系统上,你可以将所需的值重定向到/proc文件系统中的文件中,它将立即应用。原创 2024-06-10 12:30:32 · 830 阅读 · 0 评论 -
详解Socket编程-TCP_NODELAY选项
这个选项应该根据适合的场景进行判断关闭与否,例如实时性要求比较高的场景,类似用户鼠标操作,键盘输入,触摸屏事件输入,状态更新等这种连续的小分组数据,需要在对端立刻呈现,让用户尽可能感受不到延迟。但是如果网络延迟比较高,采用这种方式,那么会导致网路利用率下降。一般类似HTTP协议请求响应的模型的场景不太需要考虑禁用这个算法,因为在一条TCP连接上发送小报文,不管多小都代表了服务端任务执行的指示,完成了这个请求之后才能继续执行下一个请求,即使Sender端提前发送过去也没有作用,所以。原创 2024-06-10 11:41:15 · 989 阅读 · 0 评论 -
Nginx 参数 tcp_nodelay 详解
● 由于nginx也设置了nagle算法,如果没有收到ack,它会等着包的到来,所以就会呈现这个样子 (1)192.168.17.171首先发送一个http get请求(677号包)在发出去的数据还未被确认之前,或者说还没有收到对端的ack之前,新生成的小包是不允许被发送的。● 本文中提到了2个名词,nagle算法与延迟确认,它们看上去很相似,但是并不一样。● nagle算法在与延迟确认互相作用的情况下,会产生严重的延时效果,这是需要警惕的。(4)192.168.17.171回应ack(742号包)原创 2024-06-10 10:55:12 · 1321 阅读 · 0 评论 -
【Socket】解决TCP粘包问题
TCP一种面向连接的、可靠的、基于字节流的传输层协议。客户端发送服务端连接请求,等待服务端的回复。服务端收到请求,服务端回复客户端,可以建立连接,并等待。客户端收到回复并发送,确认连接。服务端收到回复。连接成功。四次挥手:与三次握手不同,客户端和服务端都可以主动断开连接。服务A向服务B发送FIN报文段,表示没有数据要传输服务B收到报文段,回复一个ACK报文段,表示也没有数据需要传输了。服务B发送FIN报文段,请求关闭连接。原创 2024-06-10 10:01:52 · 517 阅读 · 0 评论 -
TCP的Window Size和Scale参数对传输效率的影响
TCP协议是可靠的通信协议,数据发送方发送给数据接收方的每一个包必须需要数据接收方返回对应的ACK,否则数据发送方就需要重传这个包。这个模式就有点像我和你面对面聊天,你一句我一句。但这种方式的缺点是效率比较低的。如果你说完一句话,我在处理其他事情,没有及时回复你,那你不是要干等着我做完其他事情后,我回复你,你才能说下一句话,很显然这不现实。这样的传输方式有一个缺点:数据包的往返时间越长,通信的效率就越低。为解决这个问题,TCP 引入了滑动窗口这个概念。原创 2024-06-10 09:47:04 · 1487 阅读 · 0 评论 -
MigratoryData是如何解决C10M问题的:单个商品服务器上的1000万个并发连接
10,000,10010,000,000Hardwareunder 50%根据我们的观察,在没有minor和majorJVM垃圾收集的情况下,上述所有延迟统计信息都应该在18毫秒的中位数附近。例如,上面的最大延迟是由主要JVM垃圾回收引入的。然而,由于大规模的垃圾回收很少发生,在现实生活中,如此高的延迟每天只会发生几次。我们的客户有大规模部署(数百万最终用户),其中配置的Java虚拟机不会发生major的JVM垃圾收集。但是,在这些情况下,MigratoryData server每天都会重新启动。原创 2024-06-09 22:59:13 · 1217 阅读 · 1 评论 -
开源应用程序的架构-nginx
传统的基于进程或线程的并发连接处理模型涉及用单独的进程或线程处理每个连接,并阻塞网络或输入/输出操作。根据应用程序的不同,它在内存和CPU消耗方面可能非常低效。派生一个单独的进程或线程需要准备一个新的运行时环境,包括分配堆和堆栈内存,以及创建一个新的执行上下文。创建这些项目也花费了额外的CPU时间,由于过度的上下文切换导致线程抖动,最终可能导致性能低下。所有这些复杂的问题都体现在像Apache这样的旧web服务器架构中。这是在提供丰富的通用特性和优化服务器资源使用之间的一种权衡。原创 2024-06-09 22:00:55 · 904 阅读 · 0 评论 -
C10K 1万并发问题
花1200美元左右买一台1000MHz、2g内存和1000Mbit/s以太网卡的机器。让我们看看——20000个客户端,每个客户端就是50KHz、100Kbytes和50Kbits/秒。对于2万个客户端,每秒从磁盘中取出4千字节并将其发送到网络,不应该需要更多的马力。(顺便说一下,算下来每个客户0.08美元。一些操作系统收取的100美元/客户许可费用开始看起来有点重了!)所以硬件不再是瓶颈。1999年,最繁忙的ftp站点之一cdrom.com实际上通过千兆以太网管道同时处理了10000个客户端。原创 2024-06-09 20:56:03 · 686 阅读 · 0 评论 -
TCP 参数, Linux kernel
下面的流图表示TCP套接字客户端/服务器应答/回复流栈。连接关闭的状态转移:FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSEDTIME_WAIT转移到CLOSED可以是接收到ACK,也就是 超过2*FIN 时间在LInux下,可以使用如下更改任何参数它将把TCP/FIN超时设置为10秒,而不是默认的60秒。你也可以调整中的参数;上文例子中,参数是。原创 2024-06-09 13:48:56 · 718 阅读 · 0 评论 -
消息队列技术选型(Kafka + RocketMQ)
【摘要】 当业务需要系统间调用解耦时,MQ是一个很好的解决方案。目前选择最多的当属Kafka和阿里的RocketMQ性能指标kafkaRocketMQ适用场景日志处理适合处理业务性能单击写入TPS号称在百万条/秒大约10万条/秒可靠性使用异步刷盘,异步复制(Replication)支持异步/同步刷盘,异步/同步复制(Replication)。当业务需要系统间调用解耦时,MQ是一个很好的解决方案。备注:TPS:Transaction Per Second,每秒事务处理量。原创 2024-05-31 06:09:56 · 144 阅读 · 0 评论 -
Kafka 和 RocketMQ 之性能对比
从上面的对比来看,Kafka 在性能上综合表现确实要比 RocketMQ 更加的优秀,但在消息选型过程中,我们不仅仅要参考其性能,还有从功能性上来考虑,例如 RocketMQ 提供了丰富的消息检索功能、事务消息、消息消费重试、定时消息等。笔者个人认为通常在大数据、流式处理场景基本选用 Kafka,业务处理相关选择 RocketMQ。原创 2024-05-31 06:06:57 · 655 阅读 · 0 评论 -
零拷贝原理讲解
关于零拷贝,我们主要要解决的是问题是几次没有意义的copy,而使得数据能够直接从内核缓冲copy到网卡的buf中,为了解决这个问题,我们需要操作系统的支持。Linux内核从2.4开始,就支持这一特性。原创 2024-05-31 05:43:00 · 820 阅读 · 0 评论 -
从Java BIO到NIO再到多路复用,看这篇就够了
本文从基础概率到引出业界通用c10k问题,然后通过代码演示从BIO,到NIO再到多路复用的演进历程。原创 2024-05-19 14:38:17 · 838 阅读 · 0 评论 -
用户态与内核态 -- 帮你解惑,直达本质
系统调度资源的最小或基本单位,怎么理解呢,我想很多人其实不是特别清楚这点其实一点都不复杂,系统内核中进程一段记录专有资源和状态的 task_struct 结构体,就是一个数据结构或者理解为一个存储资源信息的对象,task_struct 结构体对于 结构体 不理解请看 C 语言语法,很简单,就是 java 中的对象,只不过 结构体 内部只有属性没有方法PCB--> PROCESS control block,也叫进程控制块。原创 2024-05-15 04:04:30 · 942 阅读 · 0 评论 -
高性能-10倍性能提升全过程
由于用户进来后先要登录并且绑定账号,实际压力先到Passport部分,在这个过程中最开始单机TPS只能到500,经过N轮优化后基本能达到5400 TPS,下面主要是阐述这个优化过程- docker bridge网络性能问题和网络中断si不均衡 (优化后:500->1000TPS)- 短连接导致的local port不够 (优化后:1000-3000TPS)- 生产环境snat单核导致的网络延时增大 (优化后能达到测试环境的3000TPS)原创 2024-02-18 17:36:21 · 730 阅读 · 0 评论 -
高性能-常见SQL-优化手段-总结
如果一个表的字段过多,索引过多,那么当这个表的数据达到一个体量后,索引占用的空间也是很多的,且修改索引时,耗费的时间也是较多的。如(name,city )和(name )这两个索引就是冗余索引,能够命中前者的查询肯定是能够命中后者的 在大多数情况下,都应该尽量扩展已有的索引而不是创建新索引。如果这个也被写满的话,就需要进行页分裂。如果不加 FOR QUERY {n}子句,默认展示最新的一次 SQL 的执行情况,加了 FOR QUERY {n},表示展示 Query_ID 为 n 的 SQL 的执行情况。原创 2024-02-13 18:43:10 · 1450 阅读 · 0 评论