话说这个背景挺惨的,某系统使用了poi-ooxml-3.5-final做excel导出功能。起初使用该版本的poi的HSSF配合多线程生成excel,没有任何问题,后来改成了XSSF生成后上线,导出3w条数据时,cpu使用率达到了100%,内存达到了100%,打死了整个服务器!
关于磁盘空间中索引节点爆满的问题还是挺多的,借此跟大家分享一下: 一、发现问题 在公司一台配置较低的Linux服务器(内存、硬盘比较小)的/data分区内创建文件时,系统提示磁盘空间不足,用df -h命令查看了一下磁盘使用情况,发现/data分区只使用了66%,还有12G的剩余空间,按理说不会出现这种问题。 二、分析问题: 后来用df -i查看了一下/data分区的索引节点(inode),发现已经用满(IUsed=100%),导致系统无法创建新目录和文件。 [root@bastion-IDC ~]# df
昨晚我发文上线了自己的网站:小林的网站上线啦!,结果发文上线不到 10 分钟, 服务器就炸了,读者疯狂跟我说网站 500 错误了。
在一次正常的活动促销之后,客服开始陆续反馈有用户反应在抢标的时候打不开网页或者APP,在打开的时候标的就已经被抢光了,刚开始没有特别的上心,觉得抢标不就是这样吗,抢小米手机的时候也不就这样吗?随着活动继续推进,有更多的用户强烈抗议,用户领了加息卷或者抵现卷之后抢不上标的,认为是平台作假故意不让使用以达到节省资源。 分析过程 其实以前也会有陆续的用户反馈不减少,给客户以小米抢手机为例子忽悠了过去,这次用户反馈太过强烈,才让我们重视了起来。我们前端一共三款产品,app、官网、H5,其中app使用量最大,官网其次
1.CPU:4核(最低需要4核起,当然可以选择更高的)CPU的选择更看重单核性能,尽量选择主频2.5GHz以上的,如果是E5处理器,最低也得E5-2670v2,多核心性能拉满
某年某月某日的一个下午,接收到监控服务器的一条告警短信:尊敬的运维工程师 XX,你好:“192.168.136.200”数据库服务器 CPU 异常,CPU 使用率 98.7%,请尽快处理。看到这个消息浑身一紧,赶紧掐灭手中的烟,跑回办公室。
在 Linux 上自建 MySQL 服务器,经常遇到各种无法启动或启动后异常的问题,本文列举一些常见问题的解决办法。
宝塔的数据库经常性自动停止,是因为网站频繁的请求数据库,而服务器内存又不足,为了保证服务器不彻底卡死,保护性的自动停止数据库,特别是有些程序比如ZBlog的数据库查询次数尤为突出,加上ZBlog插件之多,就算你不进行任何操作,你的后台也是在频繁的请求数据库!
本文讲述了一位互联网金融公司技术团队的架构师在负责抢标活动过程中,通过优化Web服务器、数据库服务器以及应用服务器等基础设施,解决了高并发问题,并实现了抢标活动的顺利进行。通过采用分布式架构以及缓存技术,解决了数据库压力过大、请求响应慢等问题,提高了系统的稳定性。同时,采用负载均衡技术,提升了系统的处理能力,最终实现了平台的高可用性。
设计一个堆溢出的程序:https://blog.csdn.net/java_wxid/article/details/103021907
在平时的开发中,使用kafka来发送数据已经非常熟悉,但是在使用的过程中,其实并没有比较深入的探索kafka使用过程中
对于线上系统调优,它本身是个技术活,不仅需要很强的技术实战能力,很强的问题定位,问题识别,问题排查能力,还需要很丰富的调优能力。
在上一个文章中详细了介绍了什么是混沌工程以及混沌工程执行的原则,和混沌工程实验中数据库调用延迟,下来详细的介绍另外一个混沌实验,也就是云服务器磁盘被写满的情况的模拟实验和解决思路。
派大星:当往线程池中提交任务的时候,会先判断线程池中线程数是否是核心线程数,如果小于,会创建核心线程并执行任务。如果线程数大于核心线程数,会判断阻塞队列是否已满,如果没有满,会把任务添加到阻塞队列中等待调度执行。如果阻塞队列已满,会判断线程数是否小于最大线程数,如果小于,会继续创建最大线程数并执行任务。如果线程数大于最大线程数,会执行拒绝策略,然后结束。
某天收到频繁的告警邮件,定时任务调度失败,查看 xxl-job 的执行器列表是空的,但是服务又显示健康,查看历史任务执行记录发现执行器是依次递减,由于是线上服务,只能先重启,然后线程日志也没有,同时尝试访问服务的健康检查接口,发现健康检查接口访问不通,应该是服务已经挂了,但是因为服务配置的是 TCP 健康检查,握手其实没问题,所以没有检测出来服务异常(血淋淋的教训)。
大家好,我是飞哥!前几天看到一个有意思的问题,我前几天在朋友圈分享了,今天再在公众号里给大家发一下。
画架构图是为了知道请求是从哪里到哪里,做性能分析一定先画个图,脑子里就会有路径的概念了。
由于本人工作原因,涉及到网络直播领域,其中视频的回放下载,涉及到了一些视频下载方面的技术。针对于一个完整视频的下载,目前市面上的主流做法是,先将整个视频流切片,存储到文件服务器中,在用户需要观看回放视频时。通过一个视频回源服务器,去文件服务器中逐个请求切片,返回给用户播放。
今天点网站发现请求不了了,到服务器查看,发现tomcat死了。 查看log 发现
Jekyll可以启动一个server服务,启动参数中有--watch(监听文件变化)和--detach(后台运行)选项,看起来这两个参数一起使用就完事了.
现在分时操作系统是通过循轮方式分配时间片进行进程调度的,如果进程在等待或阻塞,不会造成 CPU 资源使用。线程称为轻进程,共享进程资源,关于线程的调度,CPU 对于线程也是分时调度。而在 Java 中,线程的调用由 JVM 负责,线程的调度一般有两种模式,分时调度和抢占式调度。
服务器内存占用过高导致数据库服务关闭,网站无法登陆的错误详解-制作swap交换区加大内存
上一篇文章中,我们了解了一条查询语句的执行过程,按理说这篇应该讲一条更新语句的执行过程,但这个过程比较复杂,涉及到了好几个日志与事物,所以先梳理一下3个重要的日志,bin log(归档日志)、redo log(重做日志)、undo log(回滚日志)
针对以Java主导的企业级应用开发,Java虚拟机是整个项目架构的灵魂所在。只有弄清楚其内存分配及垃圾回收机制才能够在项目建设活动过程中游刃而余,无论是基于当前流行的微服务体系(以Spring家族的 Spring Cloud或以Ali家族的Dubbo)or 即将(已经)流行的服务网格体系。
最近因为太忙,时间不够,导致长时间没写笔录,没有好好去总结自己,很不应该,要调整回来。
最近我出了一本非常受欢迎的新书──《深入理解Linux网络》。在这本书中我们深入地讨论了很多内核网络模块相关的问题。讨论了一个网络包是如何从网卡到达用户进程的,聊了同步阻塞和多路复用 epoll,也详细讨论了数据是如何从进程发送出去的等等一系列深度的网络工作原理。
今天测试同学反馈API耗时很长,超过3秒的比例很高。 查看日志发现,小部分请求耗时比较大,约2秒左右,但是比例不高,与反馈比例有点不一致。后来发现是有一台服务器停止工作了(进程假死),对请求没有响应,也没有拒绝,重启后问题缓解。 因为第一次出现,没有引起重视。但是过了几个小时候,相同的问题又出现在另外一台服务器上,狗日的墨菲定律。
撸代码这么久,从之前简单的脚本,到单体应用,到最后的微服务,我们的应用总会因为各种奇奇怪怪的原因罢工,有些错误显而易见,而有些错误也会让人一时摸不到头脑。究其原因,还是需要加强自己的修养,多多总结,就能做到防患于未然。
在Redis中,经常会遇到各种原因的阻塞,最终导致Redis超时。可以毫不夸张的说,阻塞,是使用Redis的噩梦,每个人都会遇到。
其中New和Tenured属于堆内存,堆内存会从JVM启动参数(-Xmx:3G)指定的内存中分配,Perm不属于堆内存,有虚拟机直接分配,但可以通过-XX:PermSize -XX:MaxPermSize 等参数调整其大小。
在后端接口性能指标中一类重要的指标就是接口耗时。具体包括平均响应时间 TP90、TP99 耗时值等。这些值越低越好,一般来说是几毫秒,或者是几十毫秒。如果响应时间一旦过长,比如超过了 1 秒,在用户侧就能感觉到非常明显的卡顿。如果长此以往,用户可能就直接用脚投票,卸载我们的 App 了。
在互联网后端日常开发接口的时候中,不管你使用的是C、Java、PHP还是Golang,都避免不了需要调用mysql、redis等组件来获取数据,可能还需要执行一些rpc远程调用,或者再调用一些其它restful api。 在这些调用的底层,基本都是在使用TCP协议进行传输。这是因为在传输层协议中,TCP协议具备可靠的连接,错误重传,拥塞控制等优点,所以目前应用比UDP更广泛一些。 相信你也一定听闻过TCP也存在一些缺点,那就是老生常谈的开销要略大。但是各路技术博客里都在单单说开销大、或者开销小,而少见不给出具体的量化分析。不客气一点,这都是营养不大的废话。经过日常工作的思考之后,我更想弄明白的是,开销到底多大。一条TCP连接的建立需要耗时延迟多少,是多少毫秒,还是多少微秒?能不能有一个哪怕是粗略的量化估计?当然影响TCP耗时的因素有很多,比如网络丢包等等。我今天只分享我在工作实践中遇到的比较高发的各种情况。
Redis 是一个高性能的key-value数据库, 支持主从同步, 完全实现了发布/订阅机制, 因此可以用于聊天室等场景. 主要表现于多个浏览器之间的信息同步和实时更新.
内存泄漏(Memory Leak)是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放,造成系统内存的浪费,导致程序运行速度减慢甚至系统崩溃等严重后果。
这种情况下,浏览器下载时展示在状态栏上的名字,浏览器就自由发挥了,目前浏览器的命名规则是将url上的非法字符去掉,然后拼一下。
一、JVM内存模型及垃圾收集算法 1.根据Java虚拟机规范,JVM将内存划分为: New(年轻代) Tenured(年老代) 永久代(Perm) 其中New和Tenured属于堆内存,堆内存会从JVM启动参数(-Xmx:3G)指定的内存中分配,Perm不属于堆内存,有虚拟机直接分配,但可以通过-XX:PermSize -XX:MaxPermSize 等参数调整其大小。 年轻代(New):年轻代用来存放JVM刚分配的Java对象 年老代(Tenured):年轻代中经过垃圾回收没有回收掉的对象将被Cop
VisualVM is a visual tool integrating commandline JDK tools and lightweight profiling capabilities. Designed for both development and production time use.
一、发现问题: 在一台配置较低的Linux服务器(内存、硬盘比较小)的/data分区内创建文件时,系统提示磁盘空间不足,用df -h命令查看了一下磁盘使用情况,发现/data分区只使用了66%,还有12G的剩余空间,按理说不会出现这种问题。 二、分析问题: 后来用df -i查看了一下/data分区的索引节点(inode),发现已经用满(IUsed=100%),导致系统无法创建新目录和文件。
首先,我们需要肯定的是,它的出现是为了弥补php更准确的是laravel的短板:性能和资源利用率。其次,就我们现有的场景来说,更多的是开发http的相关功能。
小型.NET对象被分配到小型对象堆(SOH)上。其中有3种:第0代,第1代和第2代。对象根据其寿命向上移动。
企业平时租用和托管的服务器是有峰值承受限制的,一旦超过了该承受能力,就会导致服务器瘫痪,网站访问不了。而出现这样的直接原因就是在一段时间内,网站的访问量巨大,已经超出了服务器的承受能力。这样的例子比比皆是,以前春运期间,12306网站就频繁出现崩溃,因为那段时间网购火车票的人很多。
我们应对单台应用服务器做压力测试,你只有知道了单台能够承受多少才能知道集群能承受多少。
优化了一次前后端处理不当导致的CPU的一次爆机行为,当然,这和服务器的配置低也有着密不可分的关系,简单的逻辑学告诉我们,要找到真正的问题,进行解决,CPU爆机的关键点在于前后端两个方面,下面针对具体的问题,进行分析和解决。
随着网络的发展,用户对网站的安全防御DDoS愈加重视,作为当前一种最常见的网络攻击方式,DDoS攻击导致很多企业用户的网站业务或主机/服务器深受其害。DDoS攻击也因其“破坏性较大、难以防范,且无法彻底根除”等特点,成为云计算服务、IDC、游戏、电商等多个行业的“公敌”。
客户端先将消息写入内存缓存, 多个消息形成一个个Batch, 然后send线程将多个Batch打包成一个request发送到kafka服务器上。
到年底了,又到了各大高校开始动手采购GPU服务器的时候到了,最近不少学生在QQ上请我们帮忙看看配置
对于基于互联网的通信应用(比如IM聊天、推送系统),数据传递时使用TCP协议相对较多。这是因为在TCP/IP协议簇的传输层协议中,TCP协议具备可靠的连接、错误重传、拥塞控制等优点,所以目前在应用场景上比UDP更广泛一些。
一个简单直观的想法是直接用Hash来计算,以Key做哈希后对节点数取模。可以看出,在key足够分散的情况下,均匀性可以获得,但一旦有节点加入或退出,所有的原有节点都会受到影响,稳定性无从谈起。
领取专属 10元无门槛券
手把手带您无忧上云