Smash 1
Smash 28 天前
只运行了 100 来天,因为半年前停过电.

hadoop 2
hadoop 28 天前
带 T 的吧，从散热考虑
cxh116 3
cxh116 28 天前
低负载待机功率都差不多,满负载时才有功率差别.

个人是选不带 T,用来应对突发性能需求.
ch2 4
ch2 28 天前
不满载使用就选不带 T 的，经常满载选带 T 的
autoxbc 5
autoxbc 28 天前
带 T 的就是自带功耗墙，并不是同功率效能更高，可以说毫无用处
x86 6
x86 28 天前
@cxh116 #3 家用的能有什么突发情况
cxh116 7
cxh116 28 天前
@x86 编译东西的时候.

比如像我, 把家用服务器当开发机用, ssh 上去写代码. 主要原因是 mac 升级依赖容易挂,用 linux 不容易出现这问题.
ryd994 8
ryd994 28 天前 via Android
只有散热跟不上的情况才需要用 T
闲置时 T 不 T 都是一样的
T 就是锁了*大功率

不带 T 的应该也可以通过 XTU 锁功率
ashong 9
ashong 28 天前 via iPhone
看过 yt 上的对比，二者功耗相差无几
Danswerme 10
Danswerme 28 天前
@Smash 这个耗电情况如何？

Smash 11
Smash 28 天前
@Danswerme 没注意过电费…
SIGEV13 12
SIGEV13 28 天前
散热器够用买哪个都差不多。那点电费没什么。
如果准备常开不重启，Xeon E 系列+ ECC 内存可能更合适
HP ML30 , Microserver Gen10+都行
ZRS 13
ZRS 28 天前 via iPhone
长期开机建议使用 ECC 内存和支持的处理器
xenme 14
xenme 28 天前 via iPhone
洋垃圾都连续开好多年了，基本只有断电或者升级维护才会重启
westoy 15
westoy 28 天前
不差那点差价当然不带 T 了

带 T 的只是官锁, 不带 T 的限制一下运行模式、锁下功率和倍频其实和带 T 一样的， 同等性能功率上不会有什么区别的
wanguorui123 16
wanguorui123 28 天前
树莓派没坏，路由器电源先热坏了
q428202849 17
q428202849 25 天前
租用也不错啊
q428202849 18
q428202849 25 天前
或者拿到机房托管

1、WEB服务器访问慢
修改数据库服务器的my.ini或者my.cnf，在[mysqld]下添加skip-name-resolve

2、WEB服务器连接数据库服务器时，提示Can’t connect to MYSQL server on ‘IP’ (13)
linux系统安装的时候自动启动了selinux功能，需要关掉
修改文件/etc/selinux/config
将SELINUX设为disabled
SELINUX=disabled

我用的阿里云 30 美刀一年的悉尼服务器建站，响应特慢，各种方式都试了，无解，各位大佬有没有什么好的办法,请指教啊~不然只能丢一旁用腾讯云的去了。

美刀 悉尼 服务器 指教10 条回复 • 2017-07-22 14:07:26 +08:00
isCyan 1
isCyan 2017-07-22 11:18:24 +08:00 via Android
好办法？买张去悉尼的机票。
V 站真是水成太平洋了。
TtiGeR 2
TtiGeR 2017-07-22 11:21:04 +08:00 via iPhone
@isCyan 我在悉尼… 阿里云真的很慢
ivmm 3
ivmm 2017-07-22 11:27:16 +08:00
你是东南亚、澳洲访问悉尼，还是大陆访问悉尼？
ahean 4
ahean 2017-07-22 13:32:54 +08:00
@isCyan 伤不起啊老哥
ahean 5
ahean 2017-07-22 13:34:31 +08:00
@ivmm 大陆访问悉尼，网站跟被攻击了似的，特别慢，买的时候还在想 50M 的服务器，做网站应该挺好的吧，事实是我错了。
privil 6
privil 2017-07-22 13:36:43 +08:00
……你知道悉尼在哪么，物理意义上
ivmm 7
ivmm 2017-07-22 13:41:01 +08:00
@ahean

大陆访问悉尼机房是全球绕路的，并不像新加坡、香港、日本、硅谷走的是 CN2。

悉尼机房只推荐服务：东南亚和澳洲用户。

大陆用户推荐：新加坡，整体资费*便宜
akwIX 8
akwIX 2017-07-22 13:53:17 +08:00 via Android
@ivmm 阿里只有新加坡和香港是走 cn2 的，请勿误导
Zeroiku 9
Zeroiku 2017-07-22 14:06:15 +08:00 via iPhone
土澳土澳啊，
Zeroiku 10
Zeroiku 2017-07-22 14:07:26 +08:00 via iPhone
我一朋友澳洲留學聯機都會偶爾卡，有時雷電一來直接斷你網⋯

解决方法：

1。 改表法。

可能是你的帐号不允许从远程登陆，只能在localhost。这个时候只要在localhost的那台电脑，登入mysql后，更改 “mysql” 数据库里的 “user” 表里的 “host” 项，从”localhost”改称”%”

mysql -u root -pvmwaremysql>use mysql;

mysql>update user set host = ‘%’ where user = ‘root’;

mysql>select host, user from user;

2. 授权法。

例如，你想myuser使用mypassword从任何主机连接到mysql服务器的话。

GRANT ALL PRIVILEGES ON *.* TO ‘myuser’@’%’ IDENTIFIED BY ‘mypassword’ WITH GRANT OPTION;

FLUSH PRIVILEGES;

如果你想允许用户myuser从ip为192.168.1.6的主机连接到mysql服务器，并使用mypassword作为密码

GRANT ALL PRIVILEGES ON *.* TO ‘myuser’@’192.168.1.3’ IDENTIFIED BY ‘mypassword’ WITH GRANT OPTION;

FLUSH PRIVILEGES;

如果你想允许用户myuser从ip为192.168.1.6的主机连接到mysql服务器的dk数据库，并使用mypassword作为密码

GRANT ALL PRIVILEGES ON dk.* TO ‘myuser’@’192.168.1.3’ IDENTIFIED BY ‘mypassword’ WITH GRANT OPTION;

FLUSH PRIVILEGES;

我用的*个方法,刚开始发现不行,在网上查了一下,少执行一个语句 mysql>FLUSH RIVILEGES 使修改生效.就可以了

另外一种方法,不过我没有亲自试过的,在csdn.net上找的,可以看一下.

在安装mysql的机器上运行：

1、d:\mysql\bin\>mysql -h localhost -u root //这样应该可以进入MySQL服务器

2、mysql>GRANT ALL PRIVILEGES ON *.* TO ‘root’@’%’ WITH GRANT OPTION //赋予任何主机访问数据的权限

3、mysql>FLUSH PRIVILEGES //修改生效

4、mysql>EXIT //退出MySQL服务器

这样就可以在其它任何的主机上以root身份登录啦！

服务器就像筷子 ，数据库就像是一盘菜 程序就像人，人们用筷子夹盘子里的菜来吃。
一般来说图片保存在服务器上 确切说应该是保存在服务器主机上，服务器可以保存东西 那要数据库来做什么？数据库是用来保存数据让我们来直接调用的
就算是图片保存在服务器上也会把他的地址保存到数据库里 再通过地址来调用

内存参数：

存储引擎/共享
日志缓冲区，缓冲区池

innodb_buffer_pool_size
innodb_additional_mem_pool_size
innodb_log_buffer_size

服务器/共享
查询调整缓存
线程高速络缓存

query_cache
table_cahce
table_definition_cache

连接/会话
排序缓冲区，读取缓冲区，临时表

binlog_cache_size
read_buffer_size
read_rnd_buffer_size
join_buffer_size
sort_buffer_size
tmp_table_size
thread_cache_size
bulk_insert_buffer_size
net_buffer_length
thread_stack

下面转载自：http://www.bitscn.com/pdb/mysql/201405/227583.html

*.线程独享内存
*.全局共享内存
全局共享内存类似ORACLE的系统全局区SGA，线程独享内存类似ORACLE的进程全局区PGA

一、线程独享内存

在MySQL中，线程独享内存主要用于各客户端连接线程存储各种操作的独享数据，如线程栈信息，分组排序操作，数据读写缓冲，结果集暂存等等，而且大多数可以通过相关参数来控制内存的使用量。

* 线程栈信息使用内存(thread_stack)：
主要用来存放每一个线程自身的标识信息，如线程id，线程运行时基本信息等等，我们可以通过 thread_stack 参数来设置为每一个线程栈分配多大的内存。
Global,No Dynamic,Default 192K(32bit), 256K(32bit),
推荐配置：默认

* 排序使用内存(sort_buffer_size)：
MySQL 用此内存区域进行排序操作(filesort)，完成客户端的排序请求。当我们设置的排序区缓存大小无法满足排序实际所需内存的时候，MySQL会将数据写入磁盘文件来完成排序。由于磁盘和内存的读写性能完全不在一个数量级，
所以sort_buffer_size参数对排序操作的性能影响*对不可小视。排序操作的实现原理请参考：MySQL Order By的实现分析。
什么时候会用到？
对结果集排序时
使用确认：
可以通过查询计划中的Extra列的值为Using file-sort来证实使用了和这个缓冲区。
>explain select * from user1;
Global Session,Dynamic,Default 2M(32bit), 2M(32bit),
推荐配置：8M（内存足够的情况下），默认（内存紧张的情况）
优化建议：一种说法是增大可以提高order by,group by性能，防止数据写入磁盘占用IO资源，还有一种说法是不推荐增加这个缓冲区的大小，理由是当值太大时可能会降低查询的执行速度。目前我没有实验证实。

* Join操作使用内存(join_buffer_size)：
应用程序经常会出现一些两表（或多表）Join的操作需求，MySQL在完成某些Join需求的时候（all/index join），为了减少参与Join的“被驱动表”的读取次数以提高性能，需要使用到Join Buffer来协助完成Join操作
（具体Join实现算法请参考：MySQL中的 Join 基本实现原理）。当Join Buffer太小，MySQL 不会将该Buffer存入磁盘文件，而是先将Join Buffer中的结果集与需要Join的表进行Join操作，然后清空Join Buffer中的数据，
继续将剩余的结果集写入此Buffer中，如此往复。这势必会造成被驱动表需要被多次读取，成倍增加IO访问，降低效率。
什么时候会用到？
当查询必须连接两个表（或多个）的数据集并且不能使用索引时，这个缓冲区会被用到。这个缓冲区专门为每个线程的无索引链接操作准备的。
使用确认：
可以通过查询计划中的Extra列的值为Using join bufer来证实使用了和这个缓冲区。
>explain select * from user1;
+——+————-+——-+——-+—————+——+———+——+——+————-+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+——+————-+——-+——-+—————+——+———+——+——+————-+
| 1 | SIMPLE | user1 | index | NULL | name | 78 | NULL | 3 | Using index |
+——+————-+——-+——-+—————+——+———+——+——+————-+
Global Session,Dynamic,Default 128K 各版本平台*大值不一样
推荐配置：8M（内存足够的情况下），默认（内存紧张的情况）
优化建议：有一种说法是增加这个缓冲区的大小不会加快全连接操作的速度。目前我没有实验证实。

* 顺序读取数据缓冲区使用内存(read_buffer_size)：
这部分内存主要用于当需要顺序读取数据的时候，如无法使用索引的情况下的全表扫描，全索引扫描等。在这种时候，MySQL按照数据的存储顺序依次读取数据块，每次读取的数据快首先会暂存在read_buffer_size中，
当buffer空间被写满或者全部数据读取结束后，再将buffer中的数据返回给上层调用者，以提高效率。
Global Session,Dynamic,Default 128K
推荐配置：4M/8M

* 随机读取数据缓冲区使用内存(read_rnd_buffer_size)：
和顺序读取相反，当MySQL进行非顺序读取（随机读取）数据块的时候，会利用这个缓冲区暂存读取的数据。如根据索引信息读取表数据，根据排序后的结果集与表进行Join等等。
总的来说，就是当数据块的读取需要满足一定的顺序的情况下，MySQL就需要产生随机读取，进而使用到read_rnd_buffer_size 参数所设置的内存缓冲区。
Global Session,Dynamic,Default 256K
推荐配置：8M

* 连接信息及返回客户端前结果集暂存使用内存(net_buffer_lenth)：
这部分用来存放客户端连接线程的连接信息和返回客户端的结果集。当MySQL开始产生可以返回的结果集，会在通过网络返回给客户端请求线程之前，会先暂存在通过net_buffer_lenth所设置的缓冲区中，
等满足一定大小的时候才开始向客户端发送，以提高网络传输效率。不过net_buffer_lenth参数所设置的仅仅只是该缓存区的初始化大小，MySQL会根据实际需要自行申请更多的内存以满足需求，
但*大不会超过 max_allowed_packet 参数大小。
Global Session,Dynamic,Default 16K
推荐配置：默认 16K

* 批量插入暂存使用内存(bulk_insert_buffer_size)：
当我们使用如 insert … values(…),(…),(…)… 的方式进行批量插入的时候，MySQL会先将提交的数据放如一个缓存空间中，当该缓存空间被写满或者提交完所有数据之后，MySQL才会一次性将该缓存空间中的数据写入数据库并清空缓存。
此外，当我们进行 LOAD DATA INFILE操作来将文本文件中的数据Load进数据库的时候，同样会使用到此缓冲区。
Global Session,Dynamic,Default 8M
推荐配置：默认 8M
* 临时表使用内存(tmp_table_size)：
当我们进行一些特殊操作如需要使用临时表才能完成的Order By,Group By 等等，MySQL可能需要使用到临时表。当我们的临时表较小（小于tmp_table_size 参数所设置的大小）的时候，MySQL会将临时表创建成内存临时表，
只有当tmp_table_size所设置的大小无法装下整个临时表的时候，MySQL才会将该表创建成MyISAM存储引擎的表存放在磁盘上。不过，当另一个系统参数 max_heap_table_size 的大小还小于 tmp_table_size 的时候，
MySQL将使用 max_heap_table_size 参数所设置大小作为*大的内存临时表大小，而忽略tmp_table_size 所设置的值。而且 tmp_table_size 参数从 MySQL 5.1.2 才开始有，之前一直使用 max_heap_table_size。
谁小谁生效.另外还有一个参数max_tmp_tables,没有使用
tmp_table_size
Global Session,Dynamic,Default 16M
推荐配置：64M
max_heap_table_size
Global Session,Dynamic,Default 8M
This variable sets the maximum size to which user-created MEMORY tables are permitted to grow
这个变量定义了MEMORY存储引擎表的*大容量。
This variable is also used in conjunction with tmp_table_size to limit the size of internal in-memory tables. See
这个变量也与tmp_table_size一起使用限制内部内存表的大小。请见
http://dev.mysql.com/doc/refman/5.5/en/internal-temporary-tables.html
推荐配置：64M
主要根据业务以及服务器内存来调整，如果有需要到则可以调整到。GB居然使用2G的配置，汗

目前没有一个简便的方式来确定内部临时表的总容量。可以通过MySQL状态变量created_tmp_tables和created_tmp_disk_tables来确定创建了临时表和基于磁盘的临时表
mysql> show global status like ‘create%tables’;
+————————-+——-+
| Variable_name | Value |
+————————-+——-+
| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 0 |
+————————-+——-+
5.5中，可以使用PERFORMANCE—SCHEMA来帮助统计基于磁盘的临时表的总大小

补充说明：上面所列举的MySQL线程独享内存仅仅只是所有线程独享内存中的部分，并不是全部，只是这些可能对MySQL的性能产生较大的影响，且可以通过系统参数进行调节。
由于以上内存都是线程独享，*端情况下的内存总体使用量将是所有连接线程的总倍数。所以在设置过程中一定要谨慎，切不可为了提升性能就盲目的增大各参数值，
避免因为内存不够而产生Out Of Memory异常或者是严重的Swap交换反而降低整体性能。

二、全局共享内存

全局共享内则主要是MySQL Instance以及底层存储引擎用来暂存各种全局运算及可共享的暂存信息，如
存储查询缓存的 Query Cache，
缓存连接线程的 Thread Cache，
缓存表文件句柄信息的 Table Cache，
缓存二进制日志的 BinLog Buffer，
缓存MyISAM存储引擎索引键的 Key Buffer
存储InnoDB数据和索引的 InnoDB Buffer Pool
等等。下面针对 MySQL 主要的共享内存进行一个简单的分析。

* MyISAM索引缓存 Key Buffer（key_buffer_size）：
MyISAM 索引缓存将MyISAM表的索引信息（.MYI文件）缓存在内存中，以提高其访问性能。这个缓存可以说是影响MyISAM存储引擎性能的*重要因素之一了，通过 key_buffere_size 设置可以使用的*大内存空间。
注意：即使运行一个全部采用innodb的模式，仍需要定义一个索引码缓冲区，因为MYSQL元信息与MyISAM定义相同。
Global ,Dynamic,Default 8M
推荐配置：默认 8M
如何确认key_buffer_size不够用？
使用show full proceslist的State列中，值Repairing the keycache是一个明显的指标，它指出当前索引码缓冲区大小不足以执行当前运行的SQL语句。这将导致额外的磁盘I/O开销。

* 查询缓存 Query Cache （query_cache_size）：
http://dev.mysql.com/doc/refman/5.5/en/query-cache-configuration.html
http://dev.mysql.com/doc/refman/5.5/en/query-cache-status-and-maintenance.html
查询缓存是MySQL比较独特的一个缓存区域，用来缓存特定Query的结果集（Result Set）信息，且共享给所有客户端。通过对Query语句进行特定的Hash计算之后与结果集对应存放在Query Cache中，以提高完全相同的Query语句的相应速度。
当我们打开MySQL的Query Cache之后，MySQL接收到每一个SELECT类型的Query之后都会首先通过固定的Hash算法得到该Query的Hash值，然后到Query Cache中查找是否有对应的Query Cache。如果有，则直接将Cache的结果集返回给客户端。
如果没有，再进行后续操作，得到对应的结果集之后将该结果集缓存到Query Cache中，再返回给客户端。当任何一个表的数据发生任何变化之后，与该表相关的所有Query Cache全部会失效，所以Query Cache对变更比较频繁的表并不是非常适用，
但对那些变更较少的表是非常合适的，可以*大程度的提高查询效率，如那些静态资源表，配置表等等。为了尽可能高效的利用Query Cache，MySQL针对Query Cache设计了多个query_cache_type值
和两个Query Hint：SQL_CACHE和SQL_NO_CACHE。当query_cache_type设置为0（或者 OFF）的时候不使用Query Cache，当设置为1（或者 ON）的时候，当且仅当Query中使用了SQL_NO_CACHE 的时候MySQL会忽略Query Cache，
当query_cache_type设置为2（或者DEMAND）的时候，当且仅当Query中使用了SQL_CACHE提示之后，MySQL才会针对该Query使用Query Cache。可以通过query_cache_size来设置可以使用的*大内存空间。
Global Dynamic,Default 0
推荐配置：16M
如何确定系统query cache的情况？
show global status like ‘Qcache%’;或者
select * from information_schema.GLOBAL_STATUS where VARIABLE_NAME like ‘Qcache%’;
公式：
（Qcache_hits/Qcache_hits+Com_select+1)*100来确定查询缓存的有效性
mysql> show variables like ‘query_cache_size’;
+——————+———-+
| Variable_name | Value |
+——————+———-+
| query_cache_size | 16777216 |
+——————+———-+
1 row in set (0.00 sec)
mysql> show global status like ‘Qcache%’;
+————————-+————+
| Variable_name | Value |
+————————-+————+
| Qcache_free_blocks | 535 |
| Qcache_free_memory | 4885448 |
| Qcache_hits | 1858574835 |
| Qcache_inserts | 1619931831 |
| Qcache_lowmem_prunes | 802889469 |
| Qcache_not_cached | 825000679 |
| Qcache_queries_in_cache | 4411 |
| Qcache_total_blocks | 9554 |
+————————-+————+
8 rows in set (0.00 sec)
mysql> show global status like ‘Com_select’;
+—————+————+
| Variable_name | Value |
+—————+————+
| Com_select | 2445037535 |
+—————+————+
1 row in set (0.00 sec)

* 连接线程缓存 Thread Cache（thread_cache_size）：
连接线程是MySQL为了提高创建连接线程的效率，将部分空闲的连接线程保持在一个缓存区以备新进连接请求的时候使用，这尤其对那些使用短连接的应用程序来说可以*大的提高创建连接的效率。
当我们通过thread_cache_size设置了连接线程缓存池可以缓存的连接线程的大小之后，可以通过(Connections – Threads_created) / Connections * 100% 计算出连接线程缓存的命中率。
注意，这里设置的是可以缓存的连接线程的数目，而不是内存空间的大小。
Global,Dynamic,Default 0
推荐配置：8个
如何确定系统Thread Cache的情况？
mysql> show global status like ‘Threads_created’;
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| Threads_created | 506 |
+—————–+——-+
1 row in set (0.00 sec)

mysql> show global status like ‘connections’;
+—————+———-+
| Variable_name | Value |
+—————+———-+
| Connections | 16513711 |
+—————+———-+
1 row in set (0.00 sec)
16513711-506/16513711 * 100% =99.9938% 很高的命中率啊 这台之只读的slave

* 表缓存 Table Cache（table_open_cache）：
表缓存区主要用来缓存表文件的文件句柄信息，在 MySQL5.1.3之前的版本通过table_cache参数设置，但从MySQL5.1.3开始改为table_open_cache来设置其大小。当我们的客户端程序提交Query给MySQL的时候，
MySQL需要对Query所涉及到的每一个表都取得一个表文件句柄信息，如果没有Table Cache，那么MySQL就不得不频繁的进行打开关闭文件操作，无疑会对系统性能产生一定的影响，Table Cache 正是为了解决这一问题而产生的。
在有了Table Cache之后，MySQL每次需要获取某个表文件的句柄信息的时候，首先会到Table Cache中查找是否存在空闲状态的表文件句柄。如果有，则取出直接使用，没有的话就只能进行打开文件操作获得文件句柄信息。
在使用完之后，MySQL会将该文件句柄信息再放回Table Cache 池中，以供其他线程使用。注意，这里设置的是可以缓存的表文件句柄信息的数目，而不是内存空间的大小。
Global,Dynamic,Default 400
推荐配置：根据内存配置4G 2048 大于*大Opened_tables
如何确定系统table_open_cache的情况？
mysql> show variables like ‘table_open_cache’;
+——————+——-+
| Variable_name | Value |
+——————+——-+
| table_open_cache | 512 |
+——————+——-+
1 row in set (0.00 sec)
mysql> show global status like ‘open%_tables’;
+—————+——-+
| Variable_name | Value |
+—————+——-+
| Open_tables | 512 |
| Opened_tables | 6841 |
+—————+——-+
2 rows in set (0.00 sec)
调优参考：
http://blog.zfcms.com/article/282
http://www.kuqin.com/database/20120815/328904.html
两个参数的值。其中Open_tables是当前正在打开表的数量，Opened_tables是所有已经打开表的数量。
如果Open_tables的值已经接近table_cache的值，且Opened_tables还在不断变大，则说明mysql正在将缓存的表释放以容纳新的表，此时可能需要加大table_cache的值。对于大多数情况，比较适合的值：
Open_tables / Opened_tables >= 0.85
Open_tables / table_cache <= 0.95
如果对此参数的把握不是很准，VPS管理百科给出一个很保守的设置建议：把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Opened_tables的数值大一些，并且保证在比较高负载的*端条件下依然比Opened_tables略大。
在mysql默认安装情况下，table_cache的值在2G内存以下的机器中的值默认时256到 512，如果机器有4G内存,则默认这个值是2048，

* 表定义信息缓存 Table definition Cache （table_definition_cache）：
表定义信息缓存是从 MySQL5.1.3 版本才开始引入的一个新的缓存区，用来存放表定义信息。当我们的 MySQL 中使用了较多的表的时候，此缓存无疑会提高对表定义信息的访问效率。
MySQL 提供了 table_definition_cache 参数给我们设置可以缓存的表的数量。注意，这里设置的是可以缓存的表定义信息的数目，而不是内存空间的大小。
The number of table definitions (from .frm files) that can be stored in the definition cache. If you use a large number of tables, you can create a large table definition cache to speed up opening of tables.
Global, Dynamic, Default 400
推荐配置：根据内存配置4G 2048 和Table Cache一样即可

* 二进制日志缓冲区Binlog Cache( binlog_cache_size）：
二进制日志缓冲区主要用来缓存由于各种数据变更操做所产生的 Binary Log 信息。为了提高系统的性能，MySQL 并不是每次都是将二进制日志直接写入 Log File，而是先将信息写入 Binlog Buffer 中，
当满足某些特定的条件（如 sync_binlog参数设置）之后再一次写入 Log File 中。我们可以通过 binlog_cache_size 来设置其可以使用的内存大小，同时通过 max_binlog_cache_size 限制其*大大小
（当单个事务过大的时候 MySQL 会申请更多的内存）。当所需内存大于 max_binlog_cache_size 参数设置的时候，MySQL 会报错：“Multi-statement transaction required more than ‘max_binlog_cache_size’ bytes of storage”。
Global,Dynamic,Default 32K
推荐配置：2M

* InnoDB 日志缓冲区 InnoDB Log Buffer （innodb_log_buffer_size）：
这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。可以通过 innodb_log_buffer_size 参数设置其可以使用的*大内存空间。
注：innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：

0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步操作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新操作；
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步；
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步操作。
此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。

Global,Dynamic,Default 8M
推荐配置：8M 默认

* InnoDB 数据和索引缓存 InnoDB Buffer Pool（innodb_buffer_pool_size）：
InnoDB Buffer Pool 对 InnoDB 存储引擎的作用类似于 Key Buffer Cache 对 MyISAM 存储引擎的影响，主要的不同在于 InnoDB Buffer Pool 不仅仅缓存索引数据，还会缓存表的数据，
而且完全按照数据文件中的数据快结构信息来缓存，这一点和 Oracle SGA 中的 database buffer cache 非常类似。所以，InnoDB Buffer Pool 对 InnoDB 存储引擎的性能影响之大就可想而知了。
可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算得到 InnoDB Buffer Pool 的命中率。
global级别，不可动态变更 Default 128M
设置InnoDB数据和索引内存缓存空间大小
配置方式：配置文件中配置
选择参数：50 – 80 % RAM

mysql> show variables like ‘%innodb_buffer%’;
+——————————+———–+
| Variable_name | Value |
+——————————+———–+
| innodb_buffer_pool_instances | 1 |
| innodb_buffer_pool_size | 268435456 |
+——————————+———–+
2 rows in set (0.00 sec)
通过show global status和show engine innodb status/G的BUFFER POOL AND MEMORY
mysql> show global status like ‘%innodb_buffer%’;
+—————————————+————–+
| Variable_name | Value |
+—————————————+————–+
| Innodb_buffer_pool_pages_data | 15684 |
| Innodb_buffer_pool_bytes_data | 256966656 |
| Innodb_buffer_pool_pages_dirty | 210 |
| Innodb_buffer_pool_bytes_dirty | 3440640 |
| Innodb_buffer_pool_pages_flushed | 372378403 |
| Innodb_buffer_pool_pages_free | 1 |
| Innodb_buffer_pool_pages_misc | 698 |
| Innodb_buffer_pool_pages_total | 16383 |
| Innodb_buffer_pool_read_ahead_rnd | 0 |
| Innodb_buffer_pool_read_ahead | 691803 |
| Innodb_buffer_pool_read_ahead_evicted | 41350 |
| Innodb_buffer_pool_read_requests | 170965099291 |
| Innodb_buffer_pool_reads | 5392513 |
| Innodb_buffer_pool_wait_free | 0 |
| Innodb_buffer_pool_write_requests | 5825388207 |
+—————————————+————–+
15 rows in set (0.01 sec)

mysql> show engine innodb status/G
BUFFER POOL AND MEMORY
———————-
Total memory allocated 274726912; in additional pool allocated 0
Dictionary memory allocated 4055091
Buffer pool size 16383
Free buffers 1
Database pages 15673
Old database pages 5765
Modified db pages 521
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 27497746, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 6346456, created 1902566, written 372381712
0.00 reads/s, 0.37 creates/s, 27.75 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 15673, unzip_LRU len: 0
I/O sum[1107]:cur[0], unzip sum[0]:cur[0]
命中率 Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100%
170965099291-5392513/170965099291 × 100% = 99.99%

* InnoDB 字典信息缓存 InnoDB Additional Memory Pool（innodb_additional_mem_pool_size）:
InnoDB 字典信息缓存主要用来存放 InnoDB 存储引擎的字典信息以及一些 internal 的共享数据结构信息。所以其大小也与系统中所使用的 InnoDB 存储引擎表的数量有较大关系。不过，如果我们通过 innodb_additional_mem_pool_size 参数所设置的内存大小不够，InnoDB 会自动申请更多的内存，并在 MySQL 的 Error Log 中记录警告信息。
global级别，不可动态变更 Default 8M
设置InnoDB存放数据库字典信息的Buffer大小
推荐配置：50M

三、查看统计

1.查看各参数内存配置方式
#全局共享内存 9个变量
show variables like ‘innodb_buffer_pool_size’; /* InnoDB 数据和索引缓存（InnoDB Buffer Pool） */
show variables like ‘innodb_additional_mem_pool_size’; /* InnoDB 字典信息缓存（InnoDB Additional Memory Pool）*/
show variables like ‘innodb_log_buffer_size’; /* InnoDB 日志缓冲区（InnoDB Log Buffer） */
show variables like ‘binlog_cache_size’; /* 二进制日志缓冲区（Binlog Buffer）*/
show variables like ‘thread_cache_size’; /* 连接线程缓存（Thread Cache）*/
show variables like ‘query_cache_size’; /* 查询缓存（Query Cache）*/
show variables like ‘table_open_cache’; /* 表缓存（Table Cache） */
show variables like ‘table_definition_cache’; /* 表定义信息缓存（Table definition Cache） */
show variables like ‘key_buffer_size’; /* MyISAM索引缓存（Key Buffer） */
#*大线程数
show variables like ‘max_connections’;
#线程独享内存 6个变量
show variables like ‘thread_stack’; /* 线线程栈信息使用内存(thread_stack) */
show variables like ‘sort_buffer_size’; /* 排序使用内存(sort_buffer_size) */
show variables like ‘join_buffer_size’; /* Join操作使用内存(join_buffer_size) */
show variables like ‘read_buffer_size’; /* 顺序读取数据缓冲区使用内存(read_buffer_size) */
show variables like ‘read_rnd_buffer_size’; /* 随机读取数据缓冲区使用内存(read_rnd_buffer_size) */
show variables like ‘tmp_table_size’; /* 临时表使用内存(tmp_table_size) ，我实际计算把tmp_table_size放入全局共享内*/
也可以通过系统变量的方式直接获取
select @@key_buffer_size;
select @@max_connections

2.mysql内存计算公式
mysql使用的内存 = 全局共享内存+*大线程数×线程独享内存
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size
+max_connections*（
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size+tmp_table_size）

SET @kilo_bytes=1024;
SET @mega_bytes=@kilo_bytes*1024;
SET @giga_bytes=@mega_bytes*1024;
SELECT (@@innodb_buffer_pool_size+@@innodb_additional_mem_pool_size+@@innodb_log_buffer_size+@@binlog_cache_size+@@thread_cache_size+@@query_cache_size+@@table_open_cache+@@table_definition_cache+@@key_buffer_size+@@max_connections*(@@thread_stack+@@sort_buffer_size+@@join_buffer_size+@@read_buffer_size+@@read_rnd_buffer_size+@@tmp_table_size))/@giga_bytes AS MAX_MEMORY_GB;

这个理论*大的内存使用量，在5.5版本中tmp_table_size默认是16M，按默认u自大连接数151计算，光线程独享的临时表占据的空间都是2416M，我实际计算把tmp_table_size放入全局共享内
我的计算公式
mysql使用的内存 = 全局共享内存+*大线程数×线程独享内存
mysql used mem=innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+binlog_cache_size+thread_cache_size+query_cache_size+table_open_cache+table_definition_cache+key_buffer_size+tmp_table_size
+max_connections*（
thread_stack+sort_buffer_size+join_buffer_size+read_buffer_size+read_rnd_buffer_size）

公司为了方便，买了 edong 的 windows server 系统的服务器。

今天发现服务器访问不了外网，于是报了官方客服。过了一个小时，发现状态是处理完成，之后我登录上去，看到官方竟然是在服务器上安装 360 来修复问题，而且在进行全盘扫描。

这水平真是惊到我了。

而且问题并没有解决，还是连不了外网。

这么大一个公司的技术水平真是无法恭维。

edong 服务器 外网 修复7 条回复 • 2017-05-24 09:44:49 +08:00
binjoo 1
binjoo 2017-05-22 11:50:45 +08:00
简单粗暴，没毛病。
why1 2
why1 2017-05-22 12:46:04 +08:00 via Android
能修复？
jiangzhuo 3
jiangzhuo 2017-05-22 13:03:41 +08:00
装的是 360 企业版还是家庭版
chinafeng 4
chinafeng 2017-05-22 13:15:26 +08:00
传统 IDC 的售后技术水平一般也就那样…
leitwolf 5
leitwolf 2017-05-22 14:03:35 +08:00
@jiangzhuo 普通的

*近消息是：服务器被入侵，没法弄，叫我们备份数据，重装系统。。。

没那功能去弄这些了。
leitwolf 6
leitwolf 2017-05-22 14:03:50 +08:00
没那功夫
QQ2171775959 7
QQ2171775959 2017-05-24 09:44:49 +08:00
这个属于正常现象吧，毕竟你才给别人花费了多少钱，得到的售后的水平跟消费也是一样成比例的，当然也不排除一些技术大神做售后良心发现好给你做好各种优化及安全策略。

自打上次BCB版聚时，TR老大谈起他家里整了一台服务器的事后，令狐也心痒想整这么个东东，我则是把自己的一台闲置电脑弄成服务器用。

但是我们这些解决方案都不够好——比如成本高，耗电大，稳定性差。

所以我设想了一种专用解决方案：

用集成主板，*好是笔记本主板，耗电会省一些。用笔记本专用CPU，也是为了省电。内存硬盘光驱*好也都用笔记本版本的。

机箱可以考虑用1U的服务器机箱，主要是要处理好散热问题，保证系统的稳定性。风扇的设计可以考虑使用正压防尘方案：强制进风口加空气过滤装置，限压自然出风，以避免进灰尘。

因为不需要考虑小型化，而且不需要液晶屏和电池，估计总成本应该会比笔记本要低一些。如果这样的方案能够形成一定的标准以后指生产的话，成本就更低了。

为了提高可靠性，还可以用两块硬盘做一个RAID1。当然，如果能有便宜的家用磁带机备份方案就更好了。

结合我之前说的Web Desktop App，还可以实现远程访问使用。

其实需要服务器的人并不是只有我们这样搞技术的，我相信以后每个人——至少每个家庭都需要一台服务器，作为家庭的信息中心。

编译 node-sass，就连现在打个包都被 killed 了，怎么办好？

> ROCBOSS-UI@2.2.1 product /home/website/rocboss
> export NODE_ENV=production&&set NODE_ENV=production&&webpack –progress –colors

是否压缩文件：true
production
输出路径：web/dist/
production
78% additional chunk assetsKilled
我还专门把 mysql 关掉再编译的，还是通不过，怎么办？ 这是服务器的内存情况。

production killed node_env rocboss10 条回复 • 2017-12-08 09:47:28 +08:00
yaopingan 1
yaopingan 2017-11-28 12:25:31 +08:00 via Android
用 cnpm 被 kill 的概率会小很多
Shura 2
Shura 2017-11-28 12:31:55 +08:00
openvz 架构就这样，可能母鸡内存满了。
zouxy 3
zouxy 2017-11-28 13:23:45 +08:00 via iPhone
加 swap
asen1987 4
asen1987 2017-11-28 13:24:23 +08:00
加钱
LeungJZ 5
LeungJZ 2017-11-28 14:44:38 +08:00
@asen1987 加不了内存。
@zouxy 怎么加 swap ？
@yaopingan cnpm 难道就不用编译的了么？而且国外的服务器用 cnpm 慢的要死。
yaoliyc 6
yaoliyc 2017-11-28 17:04:14 +08:00 via iPhone
@LeungJZ 如果硬盘有富余可以试着将硬盘空间加到交换区
LeungJZ 7
LeungJZ 2017-11-28 21:54:27 +08:00
@yaoliyc 这个不会啊，而且本来就有 64 的 swap，会冲突吗？
yaopingan 8
yaopingan 2017-11-29 07:34:35 +08:00 via Android
@LeungJZ cnpm 安装模块相对内存占用少点。你到服务器进行前端代码构建，这个不是很合理啊，为啥不在本地做完?
yaoliyc 9
yaoliyc 2017-11-29 07:51:09 +08:00 via iPhone
@LeungJZ 这个需要你自己百度了，我自己买的 vps 没梦操作成功。
iceheart 10
iceheart 2017-12-08 09:47:28 +08:00 via Android
google swapon swapoff