在实际的性能测试中，会遇到各种各样的问题，比如 TPS 压不上去等，导致这种现象的原因有很多，测试人员应配合开发人员进行分析，尽快找出瓶颈所在。
腾讯云在推出轻量应用服务器Lighthouse后又推出了轻量数据库LighthouseDB。接下来就介绍一下最近使用轻量数据库LighthouseDB的感受吧。
Linux服务器配置文档找不到，你还在为查询Linux服务器硬件信息发愁吗？学会这些命令，让你轻松查看Linux服务器的CPU，内存，硬盘，SN序列号等信息，根本就不用去机房。
好久没上OSC，上面安排测下Mycat，于是申请服务器，花了两个周做出这个东西，供以借鉴。
蔡岳毅，携程酒店大数据高级研发经理，负责酒店数据智能平台研发，大数据技术创新工作。喜欢探索研究大数据的开源技术框架。
当我们接手了一台或者几台服务器的时候，首先我们有必要对服务器的基本配置有所认识，这样才可以对症下药，对以后的软件部署，系统运维会有事半功倍的效果。
最近在搞Linux下性能评测，在做CPU评测时发现了个有意思的现象，因为uos系统是自带系统监视器的，在对输入法进程检测时，发现其CPU占用率为1%：
创作不易，如果您觉得这篇文章对你有帮助，不妨给我点个赞，这将是我继续分享优质内容的动力。
进程是一个非常重要的概念，我们都知道，操作系统合理地组织、调度计算机的工作与资源。而在引入线程前，进程是操作系统进行资源分配和调度的基本单位。所以，探究Linux进程以及与进程有关的检测与控制是非常有意义的。这次内容如下。
注意：ClickHouse并非无所不能，查询语句需要不断的调优，可能与查询条件有关，不同的查询条件表是左join还是右join也是很有讲究的
当我们想搭建一个Hadoop大数据平台时，碰到的第一个问题就是我们到底该如何选择硬件。
TDSQL-C 是腾讯云自研的新一代云原生关系型数据库。融合了传统数据库、云计算与新硬件技术的优势，100%兼容 MySQL，为用户提供极致弹性、高性能、高可用、高可靠、安全的数据库服务。实现超百万 QPS 的高吞吐、PB 级海量分布式智能存储、Serverless 秒级伸缩，助力企业加速完成数字化转型。
使 /etc/sysctl.conf 的配置生效，根据实际情况来决定是否添加此命令
memcached是高性能的分布式内存缓存服务器，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度和可扩展性。 特点： 协议简单； 机遇libevent的事件处理； 内置内存存储方式； 采用不相互通信的分布式； memcached的对象实际上放置在内存中，这是如此快速的原因。 memcached如何支持高并发？ memcached使用多路复用I/O模型（epoll,select等），传统阻塞I/O中，系统可能会因为某个用户连接还没有做好I/O准备而一直等待，直到这个连接做好I/O
这个服务器一共有64个逻辑CPU，也就是我们常说的线程数，也就说每个核可以提供两个线程。
开发者利用jdbc连接hiveserver2（或者利用jdbc连接 spark HiveThriftServer2，由于两者都是提供jdbc连接到hive，因此，后面都统一称为利用jdbc连接hiveserver2），执行简单查询、复杂分析、超复杂分析等不同的sql任务，session并发量还很高（五六百甚至上千的并发），本质上要求大数据平台同时具备oltp的高并发与olap的高分析能力。对于hiveserver2这一类基于hadoop平台的jdbc server而言，非常不适合这种高并发的应用。
最近发现hiveserver2（本质上是提供jdbc连接的driver进程）经常发生严重卡死故障，而且卡死分成两种现象。
Elasticsearch 是当前流行的企业级搜索引擎，设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。作为一个开箱即用的产品，在生产环境上线之后，我们其实不一定能确保其的性能和稳定性。如何根据实际情况提高服务的性能，其实有很多技巧。这章我们分享从实战经验中总结出来的 elasticsearch 性能优化，主要从硬件配置优化、索引优化设置、查询方面优化、数据结构优化、集群架构优化等方面讲解。
在估算之前我们必须清楚这台数据库服务器的配置是什么情况，正常情况下我们需要摸清楚以下几点因素：
我们开发的软件服务需要在服务器上运行，所以服务器性能代表了软件的性能上限，因此服务器性能调优是个十分重要的环节，然而大部分同学对服务器性能调优关注的较少，今天从3个部分对服务器性能调优进行介绍，分别是：服务器配置选择，服务器负载分析，服务器内核参数调优。
腾讯云4核8g10M轻量应用服务器支持多少人同时在线？企业型-4核8G-100G-1500G，1500GB月流量，系统盘为100GB SSD盘，10M公网带宽，下载速度峰值为1280KB/s，即1.25M/秒，假设网站内页平均大小为60KB，则支持21人同时在线。腾讯云百科来详细说下4核8g10M配置轻量应用服务器支持多少人同时在线及计算方法：
系统负载能力浅析 互联网时代，高并发是一个老生常谈的话题。无论对于一个web站点还是app应用，高峰时能承载的并发请求都是衡量一个系统性能的关键标志。像阿里双十一顶住了上亿的峰值请求、订单也确实体现了阿里的技术水平（当然有钱也是一个原因）。 那么，何为系统负载能力？怎么衡量？相关因素有哪些？又如何优化呢？ 一. 衡量指标 用什么来衡量一个系统的负载能力呢？有一个概念叫做每秒请求数（Requests per second），指的是每秒能够成功处理请求的数目。比如说，你可以配置tomcat服务器的maxCon
如图所示，一个请求会先经过 Nginx 到达应用服务层，然后再去访问数据层（比如 Redis、MySQL 等），提供基本的数据功能。我们的应用服务因为要求开发效率是非常高的，所以它的运行效率是很低的，它的 qps、tps或者并发都是受限的，所以我们需要把很多这样的应用服务组成集群，向用户提供高可用服务。而一旦很多服务构成集群的时候，我们需要 Nginx 具备反向代理功能，可以把动态请求传递给应用服务。
在前面两篇文章《个人 CPU 的型号、代际架构与微架构》 和 《聊聊近些年 CPU 在微架构、IO 速率上的演进过程》 ， 我们介绍了个人台式机电脑中的 CPU 型号规则、核设计细节，以及各代 CPU 的关键变化。在这一节中，让我们进入到和大家手头工作相关度更高的服务器 CPU 原理部分。
系统硬件维护 dmesg -dT |egrep 'sda|usb|tty|memory|dma'＃查看关键信息 watch "dmesg | tail -20" #实时查看 date -d "$(awk -F. '{print $1}' /proc/uptime) second ago" +"%Y-%m-%d %H:%M:%S" # 开机运行时间 硬件资源查询 1.SN号,品牌 dmidecode | gre
RC 和 快照隔离 级别可防止某些竞争条件，但并非全部。一些棘手案例，如写偏斜 和 幻读，会发现可悲情况：
思路：现象是阻塞，通常是 CPU 彪高，导致业务线程分配不到 CPU 时间片，或者内存吃紧，频繁 GC 导致的 STW。登录到目标服务器，由于 ES 的用户不是 LZ，因此找运维要了 root 权限，登录到服务器。sudo -i 切到 root，使用 ps -ef | grep Elasticsearch 找到该用户，然后 su - es 切到 es 用户（不切是无法处理 es 用户的 Java 进程的，例如打印 jstack 日志）。 top 查看服务器状态，发现 pid 4335 进程的 CPU 占用达到 180%，查看 CPU 核数：cat /proc/cpuinfo| grep “processor”| wc -l， 核数为 4，根据经验，通常是 C2 编译器，或者 GC 线程，最后是业务代码导致。因此需要定位该线程。使用 top -Hp 4335，得到线程号 30785，使用 printf "%x" 得到 16 进制数字 7841，方便在 jstack 日志查找线程。使用 jstack -l 4335 > jstacklog.txt 打印日志，然后找线程，vim jstacklog.txt, 开始查找，gg，/7841，enter，n， 找到 "Concurrent Mark-Sweep GC Thread" os_prio=0 tid=0x00007fd380063800 nid=0x7841 runnable 这个 CMS GC 线程，看来是内存不够了。 使用 jps -l 找到 es 启动类名称，然后使用 ps aux | grep Elasticsearch 找到启动详细信息，发现启动配置为 -Xmx2g -Xms2g, -XX:CMSInitiatingOccupancyFraction=50 ，这里为了防止串行 FGC，让 CMS 在 old 区达到 50% 时就开始 GC，所以 CMS 非常繁忙。为了验证此问题，使用 jstat -gcutil 4335 1000 查看 gc 状态，发现 fgc 频繁(5 秒一次)，ygc 正常（3 秒一次） ，这里说一下，CMS 的 fgc 此时和我们想象的不一样，CMS GC 只工作在老年代，每次 GC 会对 FGC 次数加 2，一次是 init mark，一次是 remark，这两个阶段会影响暂停应用，其他的清理阶段是并行清理的，对业务线程无影响，所以，当使用 CMS GC ，如果 jstat 看到 FGC 次数很多，不用在意。但当 CMS 出现 concurrent mode failure（CMS GC 的速度赶不上对象晋升到 old 区的速度），则会使用备用收集器 Serial，开始串行 GC，此时将会彻底 STW。 因此，这个 ES 将 CMS 的阈值调的很低，就是为了防止出现 concurrent mode failure。
一. 衡量指标 用什么来衡量一个系统的负载能力呢？有一个概念叫做每秒请求数（Requests per second），指的是每秒能够成功处理请求的数目。比如说，你可以配置tomcat服务器的maxConnection为无限大，但是受限于服务器系统或者硬件限制，很多请求是不会在一定的时间内得到响应的，这并不作为一个成功的请求，其中成功得到响应的请求数即为每秒请求数，反应出系统的负载能力。 通常的，对于一个系统，增加并发用户数量时每秒请求数量也会增加。然而，我们最终会达到这样一个点，此时并发用户数量开始“压倒
最近一直在着手优化公司某些业务的大数据的查询。 数据量级大约在每天110亿个doc左右，并且通常要对最近两天的数据做一定的处理，query的响应时间比较长，因此需要优化query api响应时间。
伴随着突发流量、系统变更或代码腐化等因素，性能退化随时会发生。如在周年庆大促期间由于访问量暴涨导致请求超时无法下单；应用发布变更后，页面频繁卡顿导致客诉上升；线上系统运行一段时间后，突然发生OOM或连接打满拒绝访问。
Gavin Zhu，携程软件技术专家，负责监控系统运维开发、ES系统运维及Clickhouse技术应用推广及运维工作。
由于英特尔的代工厂仍在努力赶上竞争对手台积电提供的工艺和封装，英特尔的服务器 CPU 产品线必须“利用”代工厂的现有资源，并创造出具有适当性能和价格组合的产品，以与 X86 领域的 CPU 竞争对手 AMD 和正在数据中心创建新 CPU 层的 Arm 集团竞争。
无意间发现腾讯云服务器有个 云+ 校园 活动, 每月10 块钱一台 1 核 2 G 服务器, 还算比较划算,(其中错过了, 腾讯云修改配置可以360元五年 1核 1 G 的服务器, 阿里云服务器 279 元三年的活动 …)
Elasticsearch性能优化的最终目的：用户体验爽。 关于爽的定义——著名产品人梁宁曾经说过“人在满足时候的状态叫做愉悦，人不被满足就会难受，就会开始寻求。如果这个人在寻求中，能立刻得到即时满足，这种感觉就是爽！”。
本来看ENI文档没发现什么问题，考虑到社区小伙伴们部分刚上云还是新手。文档写的有点深度就看不懂了，所以更一篇文章写官方文档中没出现的实践操作部分。
现在云服务商对学生都是很优惠的，腾讯云学生服务器腾讯云也推出了9.9元购买云服务器的优惠活动，是一款固定的优惠套餐，包含特价云服务器、域名(加钱可选)、免费对象存储空间（6个月），但是好多用户却不知道在哪里申请，需要什么条件，流程是怎么样的，下面给大家做个介绍
最近用学校服务器跑RNA-seq数据的时候，遇到过好几次以下的情况，特别是序列比对、生成sam文件和sam转bam文件。
例如：某服务器有四个主频为3.0GHZ的CPU，每个CPU四核，超线程。可以虚拟多少VCPU口和总资源？
画架构图是为了知道请求是从哪里到哪里，做性能分析一定先画个图，脑子里就会有路径的概念了。
MySQL调优可以从几个方面来做： 1. 架构层： 做从库，实现读写分离； 2. 系统层次： 增加内存； 给磁盘做raid0或者raid5以增加磁盘的读写速度；可以重新挂载磁盘，并加上noatime参数，这样可以减少磁盘的i/o; 3. MySQL本身调优： 如果未配置主从同步，可以把bin-log功能关闭，减少磁盘i/o 在my.cnf中加上skip-name-resolve,这样可以避免由于解析主机名延迟造成mysql执行慢 调整几个关键的buffer和cache。调整的依据，主要根据数据库的状态来调试
大多数 Elasticsearch 部署往往对 CPU 要求不高。因此，相对其它资源，具体配置多少个（CPU）不是那么关键。你应该选择具有多个内核的现代处理器，常见的集群使用 2 到 8 个核的机器。如果你要在更快的 CPUs 和更多的核数之间选择，选择更多的核数更好。多个内核提供的额外并发远胜过稍微快一点点的时钟频率。
MySQL 服务器性能受制于整个系统最薄弱的环节，承载它的操作系统和硬件往往是限制因素。磁盘大小、可用内存和 CPU 资源、网络，以及所有连接它们的组件，都会限制系统的最终容量。
1.响应时间。 2.并发数。如果暂时没有对应的准确监控，针对不同业务模型，可以有不一样的并发数的预估。我们的系统进行峰值并发数预估的话，有一种比较粗略的计算方式，即全天请求平均每秒并发数 * 3。但也需要case by case。 3.吞吐量。比较常见的有QPS（每秒查询数）、HPS（每秒http请求数）以及TPS（每秒处理事务数）。 4.性能计数器。包括系统负载、线程数、cpu、内存使用情况等。可以用top、free、cat /proc/cpuinfo等命令来查看。系统负载的定义为当前被CPU执行的线程数/等待被CPU执行的总线程数。当其值与逻辑cpu个数相同时是最佳状态，其代表所有的资源都被最大限度地被利用。但也有人认为当负载为0.7倍逻辑CPU数时最佳。 1)系统负载、任务、cpu、内存使用情况：
性能测试中当我们尝试使用 Linux 命令（如 nproc 或 lscpu ）了解服务器CPU架构和性能参数时，我们经常发现我们无法正确解释其结果，因为我们混淆CPU、物理核、逻辑核概念等术语。
今天的内容包括建模优化、读写性能优化，会涉及一些简单的原理介绍。主要面向 0.8 - 0.10 版本。
相对于很多大型存储系统，Redis的配置不是很多，到了Redis3.0之后有60多个
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
