【MySQL精通之路】InnoDB配置(8)-缓存池配置

本节提供InnoDB缓冲池的配置和调优信息。

1 配置InnoDB缓冲池大小

当增加或减少innodb_buffer_pool_size时,操作是分块执行的

区块大小由innodb_buffer_pool_chunk_size 配置选项定义,默认值为128M。

缓冲池大小必须始终等于或等于(n倍于 块大小 x 缓冲池实例数)

innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的倍数。

否则缓冲池大小将自动调整为等于innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances倍数的值。

在以下示例中,innodb_buffer_pool_size设置为8G,innodl_buffer_poor_instances设置为16。innodb_buffer_pool_chunk_size为128M,为默认值。

8G是一个有效的。

8G是innodb_buffer_pool_instance=16*innob_buffer_pool_chunk_size=128M的倍数,即2G。

$> mysqld --innodb-buffer-pool-size=8G --innodb-buffer-pool-instances=16
mysql> SELECT @@innodb_buffer_pool_size/1024/1024/1024;
+------------------------------------------+
| @@innodb_buffer_pool_size/1024/1024/1024 |
+------------------------------------------+
|                           8.000000000000 |
+------------------------------------------+

在本例中,innodb_buffer_pool_size设置为9G,innodl_buffer_poor_instances设置为16。innodb_buffer_pool_chunk_size为128M,为默认值。在这种情况下,9G不是innodb_buffer_pool_instance=16*innodb_buffer_pool_chunk_size=128M的倍数,因此innodb_uffer_pool_size被调整为10G,这是innodd_buffer_pool_chunk_size*innodb_buffer_poor_instances的倍数。

$> mysqld --innodb-buffer-pool-size=9G --innodb-buffer-pool-instances=16
mysql> SELECT @@innodb_buffer_pool_size/1024/1024/1024;
+------------------------------------------+
| @@innodb_buffer_pool_size/1024/1024/1024 |
+------------------------------------------+
|                          10.000000000000 |
+------------------------------------------+

1.1 配置InnoDB缓存池块大小

innodb_buffer_pool_chunk_size可以以1MB(1048576字节)为单位增加或减少,但只能在启动时、命令行字符串或MySQL配置文件中进行修改。

命令行:

$> mysqld --innodb-buffer-pool-chunk-size=134217728

配置文件:

[mysqld]
innodb_buffer_pool_chunk_size=134217728

更改innodb_buffer_pool_chunk_size时,以下条件适用:

如果在初始化缓冲池时,新的innodb_buffer_pool_chunk_size值*innodb_buffer_pool_instances大于当前缓冲池大小,则innodb_uffer_pool_chunk_size将被截断为innodb_缓冲池_size/innodb_buffer_pool _instances。

例如,如果缓冲池被初始化为2GB(2147483648字节)的大小、4个缓冲池实例和1GB(1073741824字节)的块大小,则块大小被截断为等于innodb_buffer_pool_size/innodb_buffer_pool_instances的值,如下所示:

$> mysqld --innodb-buffer-pool-size=2147483648 --innodb-buffer-pool-instances=4
--innodb-buffer-pool-chunk-size=1073741824;
mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                2147483648 |
+---------------------------+mysql> SELECT @@innodb_buffer_pool_instances;
+--------------------------------+
| @@innodb_buffer_pool_instances |
+--------------------------------+
|                              4 |
+--------------------------------+# Chunk size was set to 1GB (1073741824 bytes) on startup but was
# truncated to innodb_buffer_pool_size / innodb_buffer_pool_instancesmysql> SELECT @@innodb_buffer_pool_chunk_size;
+---------------------------------+
| @@innodb_buffer_pool_chunk_size |
+---------------------------------+
|                       536870912 |
+---------------------------------+

缓冲池大小必须始终等于或等于innodb_Buffer_pool_chunk_size*innodb_Buffer_pool_instances的倍数。

如果您更改innodb_buffer_pool_chunk_size,innodb_buffer_pool_size会自动调整为等于innodb_uffer_pool_chunk_size*innodb_buffer_pool_instances或其倍数的值。

在初始化缓冲池时进行调整。以下示例演示了这种行为:

# The buffer pool has a default size of 128MB (134217728 bytes)mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                 134217728 |
+---------------------------+# The chunk size is also 128MB (134217728 bytes)mysql> SELECT @@innodb_buffer_pool_chunk_size;
+---------------------------------+
| @@innodb_buffer_pool_chunk_size |
+---------------------------------+
|                       134217728 |
+---------------------------------+# There is a single buffer pool instancemysql> SELECT @@innodb_buffer_pool_instances;
+--------------------------------+
| @@innodb_buffer_pool_instances |
+--------------------------------+
|                              1 |
+--------------------------------+# Chunk size is decreased by 1MB (1048576 bytes) at startup
# (134217728 - 1048576 = 133169152):$> mysqld --innodb-buffer-pool-chunk-size=133169152mysql> SELECT @@innodb_buffer_pool_chunk_size;
+---------------------------------+
| @@innodb_buffer_pool_chunk_size |
+---------------------------------+
|                       133169152 |
+---------------------------------+# Buffer pool size increases from 134217728 to 266338304
# Buffer pool size is automatically adjusted to a value that is equal to
# or a multiple of innodb_buffer_pool_chunk_size * innodb_buffer_pool_instancesmysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                 266338304 |
+---------------------------+

此示例演示了相同的行为,但具有多个缓冲池实例:

# The buffer pool has a default size of 2GB (2147483648 bytes)mysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                2147483648 |
+---------------------------+# The chunk size is .5 GB (536870912 bytes)mysql> SELECT @@innodb_buffer_pool_chunk_size;
+---------------------------------+
| @@innodb_buffer_pool_chunk_size |
+---------------------------------+
|                       536870912 |
+---------------------------------+# There are 4 buffer pool instancesmysql> SELECT @@innodb_buffer_pool_instances;
+--------------------------------+
| @@innodb_buffer_pool_instances |
+--------------------------------+
|                              4 |
+--------------------------------+# Chunk size is decreased by 1MB (1048576 bytes) at startup
# (536870912 - 1048576 = 535822336):$> mysqld --innodb-buffer-pool-chunk-size=535822336mysql> SELECT @@innodb_buffer_pool_chunk_size;
+---------------------------------+
| @@innodb_buffer_pool_chunk_size |
+---------------------------------+
|                       535822336 |
+---------------------------------+# Buffer pool size increases from 2147483648 to 4286578688
# Buffer pool size is automatically adjusted to a value that is equal to
# or a multiple of innodb_buffer_pool_chunk_size * innodb_buffer_pool_instancesmysql> SELECT @@innodb_buffer_pool_size;
+---------------------------+
| @@innodb_buffer_pool_size |
+---------------------------+
|                4286578688 |
+---------------------------+

更改innodb_buffer_pool_chunk_size时应小心,因为更改此值会增加缓冲池的大小,如上面的示例所示。

在更改innodb_buffer_pool_chunk_size之前,请计算对innodb_buffer_pool_size的影响,以确保生成的缓冲池大小是可接受的。

注意:

为了避免潜在的性能问题,块的数量(innodb_buffer_pool_size/innodb_buffer_pool_chunk_size)不应超过1000。

1.2 在线配置InnoDB缓冲池大小

innodb_buffer_pool_size配置选项可以使用set语句动态设置,允许您在不重新启动服务器的情况下调整缓冲池的大小。例如

mysql> SET GLOBAL innodb_buffer_pool_size=402653184;

注意:

缓冲池大小必须等于或等于innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances的倍数。更改这些变量设置需要重新启动服务器。

通过InnoDB API执行的活动事务和操作应在调整缓冲池大小之前完成

启动调整大小操作时,直到所有活动事务都完成后,该操作才会启动。

调整大小操作进行后,需要访问缓冲池的新事务和操作必须等待调整大小操作完成

该规则的例外情况是,当缓冲池进行碎片整理时,允许对缓冲池进行并发访问,而当缓冲池大小减小时,页面将被撤回。

允许并发访问的一个缺点是,当页面被撤回时,可能会导致可用页面暂时短缺

注意:

如果在缓冲池大小调整操作开始后启动嵌套事务,则嵌套事务可能会失败。

1.3 监视联机缓冲池调整大小的进度

Innodb_buffer_pool_resize_status变量报告一个字符串值,指示缓冲池调整大小的进度;例如

mysql> SHOW STATUS WHERE Variable_name='InnoDB_buffer_pool_resize_status';
+----------------------------------+----------------------------------+
| Variable_name                    | Value                            |
+----------------------------------+----------------------------------+
| Innodb_buffer_pool_resize_status | Resizing also other hash tables. |
+----------------------------------+----------------------------------+

Innodb_buffer_pool_resize_status变量报告一个字符串值,指示bu。从MyQL 8.0.31,您还可以使用Innodb_buffer_pool_resize_status_code和Innodb_uffer_pool_resize _status_progress状态变量来监测在线缓冲池大小调整操作,这些变量报告数值,更适合用于编程监测。

Innodb_buffer_pool_resize_status_code状态变量报告一个状态代码,指示在线缓冲池大小调整操作的阶段。状态代码包括:fer池调整进度;例如

0:没有正在进行的调整大小操作

1:开始调整大小

2:禁用AHI(自适应哈希索引)

3:撤销区块

4:收购Global Lock

5:调整池大小

6:调整哈希大小

7:调整大小失败

Innodb_buffer_pool_resize_status_progress状态变量报告一个百分比值,指示每个阶段的进度。处理完每个缓冲池实例后,将更新百分比值。当状态(由Innodb_buffer_pool_resize_status_code报告)从一种状态更改为另一种状态时,百分比值重置为0。

以下查询返回一个字符串值,指示缓冲池调整大小的进度,一个代码,指示操作的当前阶段以及该阶段的当前进度,以百分比值表示:

SELECT variable_name, variable_value FROM performance_schema.global_status WHERE LOWER(variable_name) LIKE "innodb_buffer_pool_resize%";

缓冲池调整大小的进度也可以在服务器错误日志中看到。此示例显示了在增加缓冲池大小时记录的注释:

[Note] InnoDB: Resizing buffer pool from 134217728 to 4294967296. (unit=134217728)
[Note] InnoDB: disabled adaptive hash index.
[Note] InnoDB: buffer pool 0 : 31 chunks (253952 blocks) was added.
[Note] InnoDB: buffer pool 0 : hash tables were resized.
[Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
[Note] InnoDB: completed to resize buffer pool from 134217728 to 4294967296.
[Note] InnoDB: re-enabled adaptive hash index.

此示例显示减小缓冲池大小时记录的注释:

[Note] InnoDB: Resizing buffer pool from 4294967296 to 134217728. (unit=134217728)
[Note] InnoDB: disabled adaptive hash index.
[Note] InnoDB: buffer pool 0 : start to withdraw the last 253952 blocks.
[Note] InnoDB: buffer pool 0 : withdrew 253952 blocks from free list. tried to relocate 
0 pages. (253952/253952)
[Note] InnoDB: buffer pool 0 : withdrawn target 253952 blocks.
[Note] InnoDB: buffer pool 0 : 31 chunks (253952 blocks) was freed.
[Note] InnoDB: buffer pool 0 : hash tables were resized.
[Note] InnoDB: Resized hash tables at lock_sys, adaptive hash index, dictionary.
[Note] InnoDB: completed to resize buffer pool from 4294967296 to 134217728.
[Note] InnoDB: re-enabled adaptive hash index.

从MySQL 8.0.31开始,以--log error verbose=3启动服务器,会在联机缓冲池调整大小操作期间将额外信息记录到错误日志中。附加信息包括Innodb_buffer_pool_resize_status_code报告的状态代码和Innodb_buffer_pool_resize_status_progress报告的进度百分比值。

[Note] [MY-012398] [InnoDB] Requested to resize buffer pool. (new size: 1073741824 bytes)
[Note] [MY-013954] [InnoDB] Status code 1: Resizing buffer pool from 134217728 to 1073741824
(unit=134217728).
[Note] [MY-013953] [InnoDB] Status code 1: 100% complete
[Note] [MY-013952] [InnoDB] Status code 1: Completed
[Note] [MY-013954] [InnoDB] Status code 2: Disabling adaptive hash index.
[Note] [MY-011885] [InnoDB] disabled adaptive hash index.
[Note] [MY-013953] [InnoDB] Status code 2: 100% complete
[Note] [MY-013952] [InnoDB] Status code 2: Completed
[Note] [MY-013954] [InnoDB] Status code 3: Withdrawing blocks to be shrunken.
[Note] [MY-013953] [InnoDB] Status code 3: 100% complete
[Note] [MY-013952] [InnoDB] Status code 3: Completed
[Note] [MY-013954] [InnoDB] Status code 4: Latching whole of buffer pool.
[Note] [MY-013953] [InnoDB] Status code 4: 14% complete
[Note] [MY-013953] [InnoDB] Status code 4: 28% complete
[Note] [MY-013953] [InnoDB] Status code 4: 42% complete
[Note] [MY-013953] [InnoDB] Status code 4: 57% complete
[Note] [MY-013953] [InnoDB] Status code 4: 71% complete
[Note] [MY-013953] [InnoDB] Status code 4: 85% complete
[Note] [MY-013953] [InnoDB] Status code 4: 100% complete
[Note] [MY-013952] [InnoDB] Status code 4: Completed
[Note] [MY-013954] [InnoDB] Status code 5: Starting pool resize
[Note] [MY-013954] [InnoDB] Status code 5: buffer pool 0 : resizing with chunks 1 to 8.
[Note] [MY-011891] [InnoDB] buffer pool 0 : 7 chunks (57339 blocks) were added.
[Note] [MY-013953] [InnoDB] Status code 5: 100% complete
[Note] [MY-013952] [InnoDB] Status code 5: Completed
[Note] [MY-013954] [InnoDB] Status code 6: Resizing hash tables.
[Note] [MY-011892] [InnoDB] buffer pool 0 : hash tables were resized.
[Note] [MY-013953] [InnoDB] Status code 6: 100% complete
[Note] [MY-013954] [InnoDB] Status code 6: Resizing also other hash tables.
[Note] [MY-011893] [InnoDB] Resized hash tables at lock_sys, adaptive hash index, dictionary.
[Note] [MY-011894] [InnoDB] Completed to resize buffer pool from 134217728 to 1073741824.
[Note] [MY-011895] [InnoDB] Re-enabled adaptive hash index.
[Note] [MY-013952] [InnoDB] Status code 6: Completed
[Note] [MY-013954] [InnoDB] Status code 0: Completed resizing buffer pool at 220826  6:25:46.
[Note] [MY-013953] [InnoDB] Status code 0: 100% complete

1.4 在线缓冲池内部调整大小

调整大小操作由后台线程执行。当增加缓冲池的大小时,调整大小操作:

按块添加页面(块大小由innodb_buffer_pool_chunk_size定义)

转换哈希表、列表和指针以使用内存中的新地址

将新页面添加到可用列表

在进行这些操作时,会阻止其他线程访问缓冲池。

当减小缓冲池的大小时,调整大小操作:

对缓冲池进行碎片整理并提取(释放)页面

按块删除页面(块大小由innodb_buffer_pool_chunk_size定义)

转换哈希表、列表和指针以使用内存中的新地址

在这些操作中,只有对缓冲池进行碎片整理和撤回页面才能允许其他线程同时访问缓冲池。

2 配置多个缓冲池实例

对于缓冲池在千兆字节范围内的系统,将缓冲池划分为单独的实例可以通过减少不同线程读取写入缓存页面时的争用来提高并发性。

此功能通常适用于缓冲池大小在千兆字节范围内的系统。

使用innodb_buffer_pool_instances配置选项配置多个缓冲池实例,还可以调整innodb_buffer_pool_size值。

当InnoDB缓冲池很大时,可以通过从内存中检索来满足许多数据请求。

您可能会遇到多个线程试图同时访问缓冲池的瓶颈。

您可以启用多个缓冲池来最大限度地减少这种争用。

使用哈希函数,将存储在缓冲池中或从缓冲池中读取的每个页面随机分配给其中一个缓冲池

每个缓冲池管理自己的空闲列表、刷新列表、LRU以及连接到缓冲池的所有其他数据结构。

在MySQL 8.0之前,每个缓冲池都由自己的缓冲池互斥体保护。

在MySQL 8.0及更高版本中,缓冲池互斥被几个列表哈希保护互斥所取代,以减少争用。

要启用多个缓冲池实例,请将innodb_buffer_pool_instances配置选项设置为大于1(默认值)到64(最大值)的值。

只有将innodb_buffer_pool_size设置为1GB或更大时,此选项才会生效。

您指定的总大小在所有缓冲池中分配。

为了获得最佳效率,请指定innodb_buffer_pool_instancesinnodb_buffer_pool_size的组合,以便每个缓冲池实例至少为1GB。

3 使缓冲池抗扫描

InnoDB没有使用严格的LRU算法,而是使用了一种技术来最大限度地减少被带入缓冲池且不再被访问的数据量。(一句话解释就是减少热数据的误判率)

目标是确保频繁访问(“热”)页面保留在缓冲池中,即使预读全表扫描带来新的块,这些块可能在以后访问,也可能不会访问。

新读取的块被插入LRU列表的中间所有新读取的页面都插入到距离LRU列表尾部3/8的位置

第一次在缓冲池中访问页面时,页面会移动到列表的前面(最近使用的末尾)。

因此,从未访问过的页面永远不会出现在LRU列表的前面部分,并且比使用标准的LRU方法更快地“老化”。

这种设计将LRU列表分为两段,其中插入点下游的页面被认为是“旧的”,是LRU驱逐的理想候选块

有关InnoDB缓冲池的内部工作原理和LRU算法的具体说明,请参阅下面博客中的“缓存池”。

【MySQL精通之路】InnoDB(5)-内存结构-CSDN博客

您可以控制LRU列表中的插入点,并选择InnoDB是否对通过索引扫描带入缓冲池的块应用相同的优化。

配置参数innodb_old_block_pct控制LRU列表中“旧”块的百分比

innodb_old_block_pct的默认值为37,对应于原始的固定比率3/8。该值范围为5(缓冲池中的新页面很快老化)到95(只有5%的缓冲池保留给热页面,使算法接近于熟悉的LRU策略)。

防止缓冲池被预读搅动的优化可以避免由于表或索引扫描而引起的类似问题。

在这些扫描中,数据页通常会被快速连续访问几次,并且再也不会被查询。配置参数innodb_old_block_time指定第一次访问页面后的时间窗口(以毫秒为单位),在此期间可以访问页面而不必移动到LRU列表的前端(最近使用的端)。innodb_old_block_time的默认值为1000。增加该值会使越来越多的块从缓冲池中更快地老化。

innodb_old_block_pctinnodb_ld_block_time都可以在MySQL选项文件(my.cnf或my.ini)中指定,也可以在运行时使用SET GLOBAL语句进行更改。

在运行时更改值需要足够的权限来设置全局系统变量。参见“系统变量权限”。

【MySQL精通之路】系统变量-系统变量权限-CSDN博客

为了帮助您评估设置这些参数的效果,SHOW ENGINE INNODB STATUS命令报告缓冲池统计信息。

有关详细信息,请参阅使用InnoDB标准监视器监视缓冲池。

由于这些参数的影响可能因硬件配置、数据和工作负载的详细信息而异,因此在任何性能关键型或生产环境中更改这些设置之前,请始终进行基准测试以验证其有效性

混合工作负载中,大多数活动都是OLTP类型的,具有周期性的批处理报告查询,这会导致大量扫描,在批处理运行期间设置innodb_old_block_time的值可以帮助将正常工作负载的工作集保留在缓冲池中

当扫描无法完全容纳在缓冲池中的大表时,将innodb_old_block_pct设置为小值可以防止只读取一次的数据占用缓冲池的很大一部分

例如,设置innodb_old_block_pct=5将只读取一次的数据限制为缓冲池的5%。

当扫描适合内存的小表时,在缓冲池中移动页面的开销较小,因此可以将innodb_old_block_pct保留为默认值,甚至更高,例如innodb_ld_block_pct=50。

innodb_old_block_time参数的影响比innodb_ld_block_pct参数更难预测,相对较小,并且随着工作负载的变化而变化更大。

要获得最佳值,如果通过调整innodb_old_block_pct的性能改进还不够,请执行自己的基准测试。

4 配置InnoDB缓冲池预取(预读)

预读请求是一种I/O请求,用于异步预取缓冲池中的多个页面,以应对即将到来的对这些页面的需求。

这些请求将所有页面放在一个范围内。InnoDB使用两种预读算法来提高I/O性能:

线性预读是一种根据缓冲池中按顺序访问的页面来预测可能很快需要哪些页面的技术。

通过使用配置参数InnoDB_read_ahead_threshold调整触发异步读取请求所需的有序页面访问次数,可以控制InnoDB何时执行预读操作。

在添加此参数之前,InnoDB只会在读取当前数据块的最后一页时计算是否对整个下一个数据块发出异步预取请求。

配置参数innodb_read_ahead_threshold控制innodb在检测顺序页面访问模式时的敏感度

如果从一个数据块顺序读取的页数大于或等于innodb_read_ahead_threshold,innodb将启动整个后续数据块的异步预读操作

innodb_read_ahead_threshold可以设置为0-64之间的任何值。

默认值为56。该值越高,访问模式检查就越严格。

例如,如果将该值设置为48,则只有当顺序访问了当前扩展区中的48个页面时,InnoDB才会触发线性预读请求

如果该值为8,即使按顺序访问数据块中只有8个页面,InnoDB也会触发异步预读。

您可以在MySQL配置文件中设置此参数的值,也可以使用SET GLOBAL语句动态更改它

这需要足够的权限来设置全局系统变量。参见“系统变量权限”。

随机预读是一种技术,它根据缓冲池中已经存在的页面来预测何时可能很快需要其他页面,而不管这些页面的读取顺序如何。

如果在缓冲池中发现来自同一数据块的13个连续页面,InnoDB将异步发出一个请求,以预取数据块的剩余页面

要启用此功能,请将配置变量innodb_random_read_ahead设置为ON。

SHOW ENGINE INNODB STATUS命令显示统计信息,以帮助您评估预读算法的有效性。

统计信息包括以下全局状态变量的计数器信息:

Innodb_buffer_pool_read_ahead

Innodb_buffer_pool_read_ahead_evicted

Innodb_buffer_pool_read_ahead_rnd

微调innodb_random_read_ahead设置时,此信息非常有用。

有关I/O性能的更多信息,请参阅“优化InnoDB磁盘I/O”和“优化磁盘I/O”。

5 配置缓冲池刷新

6 保存和恢复缓冲池状态

7 从核心文件中排除缓冲池页面

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/bicheng/14198.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

最近情况说明

最近转入了Django开发工作,所以主要方向在Python开发。大大

Ubuntu 搭建SRT协议 环境

1.官网clone源码 GitHub - Haivision/srt: Secure, Reliable, Transport 打不开的话国内gitee 不是最新的 https://gitee.com/smartavs/srt.git 下下来之后 cd 到srt目录 需要安装cmake openssl等依赖 我的环境已经有了 mkdir build && cd build cmake .. -…

Docker Update 用法详解

Docker 是一个开源的应用容器引擎,它让开发者可以打包应用及其依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上。docker update命令则是用于在容器运行时动态更新其配置,如资源限制、CPU权重等,而无需重启容器。本…

最有效的企业数据防泄漏手段 | 数据泄漏防护系统推荐

随意信息安全意识不断提高,企业纷纷寻求高效的数据防泄漏手段。在众多解决方案中,这五款软件各具特色,但它们的共同目标都是确保企业数据的安全性和保密性。 接下来,我们将逐一介绍这五款软件的特点和优势。 1、Ping 32 Ping32…

前端项目使用docker编译发版和gitlab-cicd发版方式

项目目录 app/ ├── container/ │ ├── init.sh │ ├── nginx.conf.template ├── src/ ├── .gitlab-ci.yml └── deploy.sh └── Dockerfile └── Makefilecontainer目录是放nginx的配置文件,给nginx镜像使用 .gitlab-ci.yml和Makefile是c…

阿里云 EMR Serverless Spark 版开启免费公测

阿里云 EMR Serverless Spark 版是一款云原生,专为大规模数据处理和分析而设计的全托管 Serverless 产品。它为企业提供了一站式的数据平台服务,包括任务开发、调试、调度和运维等,极大地简化了数据处理的全生命周期工作流程。使用 EMR Serve…

LayUI使用(一)点击树组件的右边空白区域也可响应事件

前提: 如下,希望能够点击右边的空白区域也能够响应,而不仅仅是点击文本才响应 分析流程 一开始问了chatgpt,但它给的方案太麻烦了,而且还有错误,因此自己上手F12进入调试模式,点击查看最终渲…

工作流之节点回退, 回退到上一个节点

工作流审批流程会遇到, 审批不通过, 回退到指定节点, 或者回退到上一个节点. 回退到指定节点, 通过moveTo 实现 回退到上一个节点, 假如当前节点流入得分支有很多, 该如何判断上个节点是谁呢? 上一个节点是谁 根据流程的节点记录判断, 按照时间倒序, 找到上一个办理节点. …

文件外发审核是数据防泄漏的重要手段,那该怎么落地?

企业在日常经营中,无可避免地会产生文件外发的需求,文件发送对象包括但不限于合作方、供应商、客户、公关媒体、慈善组织等等,不一而足。而由于外发的对象不同,所涉及的文件类型也多种多样: 商业合作合同:…

STM32开发学习——使用 Cortex-M3M4M7 故障异常原因与定位(三)

STM32开发学习——使用 Cortex-M3M4M7 故障异常原因与定位(三) 文章目录 STM32开发学习——使用 Cortex-M3M4M7 故障异常原因与定位(三)文档说明:官方参考文档线上链接(可在线阅读与下载)&#…

AWS数据库之Amazon RDS

Amazon RDS 是一种 Web 服务,它让用户能够在云中轻松设置、运行和扩展关系数据库。它在承担耗时的数据库管理任务的同时,又可提供经济高效的可调容量,使您能够腾出时间专注于应用程序和业务。 Amazon RDS - AWS 定价的工作原理

【Python脚本随手笔记】-- 将 “庆余年2” 等信息写入 Txt 文件中

💌 所属专栏:【Python脚本随手笔记】 😀 作  者:我是夜阑的狗🐶 🚀 个人简介:一个正在努力学技术的CV工程师,专注基础和实战分享 ,欢迎咨询! &#…

《Effective Objective-C 2.0》读书笔记——接口与API设计

目录 第三章:接口与API设计第15条:用前缀避免命名空间冲突第16条:提供“全能初始化方法”第17条:实现description方法第18条:尽量使用不可变对象第19条:使用清晰而协调的命名方式第20条:为私有方…

Altair® Squeak and Rattle Director™ 品质认知度解决方案

Altair Squeak and Rattle Director™ 品质认知度解决方案 借助 Altair 的 Squeak and Rattle Director,计算机辅助工程 (CAE) 的工程专业人士和初学者都能在早期设计阶段快速识别并消除产品中的异响。通过在简化的半自动化流程(已完全集成到 Altair Hy…

【ELK日志收集过程】

文章目录 为什么要使用ELK收集日志ELK具体应用场景ELK日志收集的流程 为什么要使用ELK收集日志 使用 ELK(Elasticsearch, Logstash, Kibana)进行日志收集和分析有多种原因。ELK 堆栈提供了强大、灵活且可扩展的工具集,能够满足现代 IT 系统对…

在Spring Boot中Redis实现事务有哪些方式?

在Spring Boot中操作Redis并实现事务有多种方式,常见的有以下几种: 1. 使用Spring Data Redis的SessionCallback Spring Data Redis提供了SessionCallback接口,允许你在一个会话中执行多个Redis操作,从而实现事务。具体步骤如下…

VMware ESXI 7.0安装部署

1、为什么要虚拟化? 目前,物理服务器存在以下几个问题: 1)硬件资源利用率低; 2)可靠性不足,物理服务器宕机即可造成整体业务停摆; 3)维护量大,无法实现统…

7个常见的SQL慢查询问题及其解决方法

大家好,得益于摩尔定律,计算机性能已大幅提升,加上数据库的进步以及微服务所倡导的各种反模式设计,因此现在编写复杂SQL查询的机会越来越少。业界已经开始提倡不要进行专门的SQL优化,因为节省下来的资源并不足以抵消员…

人工智能的明天:机器学习与自动化的演进之旅

方向一:技术革新与行业应用 现状分析: 当前的IT行业正处于一个技术革新的高峰期。量子计算虽然还处于研究和开发阶段,但其潜力巨大,未来可能在药物发现、材料科学和复杂系统模拟等领域带来突破。虚拟现实(VR&#xff…

JAVA面试题大全(九)

1、为什么要使用 spring? 方便解耦,便于开发支持aop编程声明式事务的支持方便程序的测试方便集成各种优秀的框架降低JavaEE API的使用难度 2、解释一下什么是 aop? AOP 是 Aspect-Oriented Programming 的缩写,中文翻译为“面向…