CDN缓存服务器现状,squid、nginx、trafficserver、ATS性能测试

今天谈一个问题,目前cache软件在业界的使用现状。cache系统其实最大的使用场景,还是主要集中在CDN厂商里。

大概在2010年之前,各大CDN厂商基本清一色的使用squid。那时候的squid是绝对的主力。

squid的作为cache领域的鼻祖,正是由于历史的久远,很多近10年左右流行起来的很多系统特性,它本身并不支持。比如sendfile,splice和多核等方面的支持,由于这些特性属于核心架构方面的功能,后期如果想引进的话,需要对squid的核心做大量的修改。对于CDN厂商来说,稳定性是大于性能上的考量的。所以在面临业务增长的性能压力之下,几乎各个厂商内部的cache团队都要去忍痛,咬着牙去做这些大伤元气的改造。

就拿多核的支持来说,因为squid本身是单进程架构,基本上大家的处理方式就是起多实例,所谓的多实例,就是启动多个squid,通过这样的方式让它可以起到多进程的效果。(心好累

当然除了squid之外,还有一个比较新的cache,就是varnish。varnish的作者曾经在自己的博客上批评过squid中很多过时的思想。宣称自己的性能和架构要比squid强大很多。但是作为一个只支持内存的缓存系统(有可以持久化的外围手段),使用的场景是有限的。目前使用varnish的,都是一些小站,或者说热点很集中,缓存总量不大的业务场景。在前几年,我了解到新浪微博有在用它。

阅读剩余部分 -

查看 SELinux状态及关闭SELinux

查看SELinux状态:

1、/usr/sbin/sestatus -v      ##如果SELinux status参数为enabled即为开启状态

SELinux status:                 enabled

2、getenforce                 ##也可以用这个命令检查

关闭SELinux:

1、临时关闭(不用重启机器):

setenforce 0                  ##设置SELinux 成为permissive模式

                              ##setenforce 1 设置SELinux 成为enforcing模式

2、修改配置文件需要重启机器:

修改/etc/selinux/config 文件

将SELINUX=enforcing改为SELINUX=disabled

重启机器即可

阅读剩余部分 -

linux记录系统中常用重要的log记录和用户的所有操作精确命令记录

常见的几个登录文件有:

/var/log/secure:记录登入系统存取数据的文件,例如 pop3, ssh, telnet, ftp 等都会被记录;

/var/log/wtmp:记录登入者的讯息数据,由于本文件已经被编码过,所以必须使用 last指令来取出文件的内容;

/var/log/messages:尤为重要,几乎发生的错误讯息(或是重要信息)都会被记录在此;

/var/log/boot.log:记录开机或者是一些服务启动的时候,所显示的启动或关闭讯息;

/var/log/maillog 或 /var/log/mail/*:纪录邮件存取或往来( sendmail 与 pop3 )的使用者记录;

/var/log/cron:记录 crontab 这个例行性服务的内容的。

/var/log/httpd, /var/log/news, /var/log/mysqld.log, /var/log/samba, /var/log/procmail.log:分别是几个不同的网络服务的记录文件!

登录文件的纪录程序之一: syslogd

通常经过 syslog 而记录下来的数据主要有:

事件发生的日期与时间;

发生此事件的主机名称;

启动此事件的服务名称 (如 samba, xinetd 等) 或函式名称 (如 libpam ..);

该讯息数据内容

syslogd的daemon配置文件:/etc/syslog.conf

内容语法是这样的:

服务名称[.=!]讯息等级          讯息记录的文件名或装置或主机

# 例如底下:

mail.info                      /var/log/maillog_info

阅读剩余部分 -

CentOS7 禁用Transparent Huge Pages的实现方法

CentOS7 禁用Transparent Huge Pages

自CentOS6版本开始引入了Transparent Huge Pages(THP),从CentOS7版本开始,该特性默认就会启用。尽管THP的本意是为提升内存的性能,不过某些数据库厂商还是建议直接关闭THP(比如说ORACLE、MariaDB、MongoDB等),否则可能会导致性能出现下降。

首先检查THP的启用状态:

[root@localhost ~]# cat /sys/kernel/mm/transparent_hugepage/defrag
[always] madvise never
[root@localhost ~]# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

这个状态就说明都是启用的。

我们这个时候当然可以逐个修改上述两文件,来禁用THP,但要想一劳永逸的令其永久生效,还是参考下列的步骤。

阅读剩余部分 -

sphinx创建索引错误sql_fetch_row: Lost connection to MySQL server during query

Sphinx是一个基于SQL的全文检索引擎,可以结合MySQL,PostgreSQL做全文搜索,它可以提供比数据库本身更专业的搜索功能,使得应用程序更容易实现专业化的全文检索。Sphinx特别为一些脚本语言设计搜索API接口,如PHP,Python,Perl,Ruby等,同时为MySQL也设计了一个存储引擎插件。

 

 

本文为大家讲解的是sphinx创建索引错误sql_fetch_row: Lost connection to MySQL server during query解决方法,感兴趣的同学参考下。

错误描述

在进行索引创建的时候,出现了错误
Error: sql_fetch_row: Lost connection to MySQL server during query

完整错误如下

$ /usr/local/sphinx/bin/indexer --config /usr/local/sphinx/etc/sphinx.conf --all --rotate
Sphinx 0.9.8-rc2 (r1234)
Copyright (c) 2001-2008, Andrew Aksyonoff

using config file '/usr/local/sphinx/etc/sphinx.conf'...
indexing index 'orthodb'...
ERROR: index 'orthodb': sql_fetch_row: Lost connection to MySQL server during query.
total 2087306 docs, 18785754 bytes
total 2462.060 sec, 7630.10 bytes/sec, 847.79 docs/sec

阅读剩余部分 -

sphinx 配置文件全解析

sphinx的配置文件是在配置的时候最容易出错的了:

我们先要明白几个概念:

  • source:数据源,数据是从什么地方来的。
  • index:索引,当有数据源之后,从数据源处构建索引。索引实际上就是相当于一个字典检索。有了整本字典内容以后,才会有字典检索。
  • searchd:提供搜索查询服务。它一般是以deamon的形式运行在后台的。
  • indexer:构建索引的服务。当要重新构建索引的时候,就是调用indexer这个命令。
  • attr:属性,属性是存在索引中的,它不进行全文索引,但是可以用于过滤和排序。

sphinx的配置文件过于冗长,我们把sphinx默认的配置文件中的注释部分去掉,重新进行描述理解,就成下面的样子了:

阅读剩余部分 -

sphinx配置文件详解

sphinx的配置:

其结构组成主要如下:

Source 源名称1{                //指定数据源

一些配置

}

Index 索引名称1{

Source=源名称1

}

Source 源名称2{

一些配置

}

Index 索引名称2{

Source=源名称2

}

Indexer{

mem_limit = 32M

}

Searchd{                             //配置 searchd 守护程序本身

}

阅读剩余部分 -

MySQL Waiting for table metadata lock故障分析

源起

线上执行ALTER时,通过show processlist查看到出现Waiting for table metadata lock ,导致后面的查询都无法执行。

5217122 | create_table_04 | 172.100.207.148:31291 | finance | Query   | 1829 | Waiting for table metadata lock  | ALTER TABLE `Pay` MODIFY COLUMN `pay`  smallint(6) NULL DEFAULT 0 COMMENT '付??'
5217155 | bx_live_dml     | 172.100.210.4:34730   | finance | Prepare | 1714 | Waiting for table metadata lock  | select * from Pay where (pay =4 or pay =8) and projectId ='CSZY0'

由于当时直接把ALTER给kill了,所以基本没有现场,所以下面模拟什么情况MySQL产生这种事故。

MySQL元数据锁

MySQL DBA对于Waiting for table metadata lock肯定不会陌生,一般都是进行alter操作时被堵住了,导致了我们在show processlist 时,看到线程的状态是在等metadata lock。

为了在并发环境下维护表元数据的数据一致性,在表上有活动事务(显式或隐式)的时候,不可以对元数据进行写入操作。因此从MySQL5.5版本开始引入了MDL锁(metadata lock),来保护表的元数据信息,用于解决或者保证DDL操作与DML操作之间的一致性。对于引入MDL,其主要解决了2个问题,一个是事务隔离问题,比如在可重复隔离级别下,会话A在2次查询期间,会话B对表结构做了修改,两次查询结果就会不一致,无法满足可重复读的要求;另外一个是数据复制的问题,比如会话A执行了多条更新语句期间,另外一个会话B做了表结构变更并且先提交,就会导致slave在重做时,先重做alter,再重做update时就会出现复制错误的现象。

阅读剩余部分 -