PostgreSQL案例：planning time超长问题分析

news2024/9/20 13:19:23

问题分析概述

库总是OOM，分析到是执行计划生成有问题，planning time 1秒，planning shared hit 100w。一通分析，定位到是统计信息基表pg_statistic膨胀，由于会话首次SQL执行时的CatCacheMiss，导致backend访问并缓存了pg_statistic过多的死元组数据。应用连接总会启用新会话，多个backend的总内存过大从而导致OOM。

下面是详细分析过程。

问题现象

某库反复OOM和重启。经过一通问题排查，发现会话连接数不多，但是每个会话的内存占用比较高，总内存超过内存cg限制导致OOM。
初步可以排除以下原因：

  • 不是元数据过多的问题导致。对象过多（一般是分区数太多）会导致会话缓存过多的元数据。这个库的对象不算多
  • 不是sql执行计划问题。排序/hash可能使用过多内存。这个库不是这个场景，sql可以是一个顺序扫描。

在问题分析过程中发现，库里面执行任意一个简单sql执行时间很长，并且 Planning Buffers有约100w

 explain (analyze,buffers,timing) select * from  lzlinfo limit 1;
                                                     QUERY PLAN                                                     
--------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..1.02 rows=1 width=71) (actual time=0.011..0.012 rows=1 loops=1)
   Buffers: shared hit=1
   ->  Seq Scan on lzlinfo  (cost=0.00..480.73 rows=473 width=71) (actual time=0.010..0.010 rows=1 loops=1)
         Buffers: shared hit=1
 Planning:
   Buffers: shared hit=1127312   --异常planning shared hit
 Planning Time: 947.038 ms  --异常planning time
 Execution Time: 0.035 ms
(8 rows)

再执行一次sql，planning time就正常了。

问题定位过程

打印执行计划的stat信息

把会话的执行计划各阶段的stat信息打到日志：

set log_parser_stats   =on;
set log_planner_stats  =on;
set log_executor_stats   =on;

然后跑下sql，日志输出如下：


2024-08-13 10:02:33.936 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,13,"idle",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PARSER STATISTICS","! system usage stats:
!       0.000046 s user, 0.000046 s system, 0.000091 s elapsed
!       [0.001661 s user, 0.001661 s system total]
!       4660 kB max resident size
!       0/0 [0/8] filesystem blocks in/out
!       0/36 [0/996] page faults/reclaims, 0 [0] swaps
!       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
!       0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from  lzlinfo
2024-08-13 10:02:33.938 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,14,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PARSE ANALYSIS STATISTICS","! system usage stats:
!       0.001459 s user, 0.000000 s system, 0.001464 s elapsed
!       [0.003146 s user, 0.001687 s system total]
!       5972 kB max resident size
!       0/0 [0/8] filesystem blocks in/out
!       0/325 [0/1324] page faults/reclaims, 0 [0] swaps
!       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
!       0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from  lzlinfo
2024-08-13 10:02:33.938 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,15,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"REWRITER STATISTICS","! system usage stats:
!       0.000001 s user, 0.000000 s system, 0.000001 s elapsed
!       [0.003177 s user, 0.001687 s system total]
!       5972 kB max resident size
!       0/0 [0/8] filesystem blocks in/out
!       0/0 [0/1324] page faults/reclaims, 0 [0] swaps
!       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
!       0/0 [5/0] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from  lzlinfo
2024-08-13 10:02:34.644 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,16,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"PLANNER STATISTICS","! system usage stats:
!       0.539964 s user, 0.164083 s system, 0.705718 s elapsed
!       [0.543248 s user, 0.165770 s system total]
!       745072 kB max resident size   --异常点
!       0/0 [0/8] filesystem blocks in/out
!       0/184803 [0/186157] page faults/reclaims, 0 [0] swaps
!       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
!       0/1 [5/1] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from  lzlinfo
2024-08-13 10:02:34.644 CST,"postgres","lzldb",85532,"[local]",66babe8c.14e1c,17,"EXPLAIN",2024-08-13 10:01:48 CST,4/713,0,LOG,00000,"EXECUTOR STATISTICS","! system usage stats:
!       0.540248 s user, 0.164170 s system, 0.706088 s elapsed
!       [0.543532 s user, 0.165857 s system total]
!       745596 kB max resident size
!       0/0 [0/8] filesystem blocks in/out
!       0/184898 [0/186252] page faults/reclaims, 0 [0] swaps
!       0 [0] signals rcvd, 0/0 [0/0] messages rcvd/sent
!       0/1 [5/1] voluntary/involuntary context switches",,,,,"explain (analyze,buffers) select *,1 from  lzlinfo
"

planner阶段内存使用率暴涨，elapsed time也暴涨。这部分信息可以定位到是整个planning阶段中的planner阶段有问题。其他可用信息不多。

strace追踪

strace -p 76419

strace: Process 76419 attached
epoll_wait(4, [{EPOLLIN, {u32=15422552, u64=15422552}}], 1, -1) = 1
recvfrom(9, "Q\0\0\0\262explain (analyze,buffers) s"..., 8192, 0, NULL, NULL) = 179
lseek(5, 0, SEEK_END)                   = 8192
brk(NULL)                               = 0xfed000
brk(0x100e000)                          = 0x100e000
brk(NULL)                               = 0x100e000
brk(NULL)                               = 0x100e000
brk(0x1007000)                          = 0x1007000
brk(NULL)                               = 0x1007000
mmap(NULL, 270336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b7806b0c000
open("base/17076/16678", O_RDWR)        = 7
lseek(7, 0, SEEK_END)                   = 0
open("base/17076/46160", O_RDWR)        = 12
lseek(12, 0, SEEK_END)                  = 7667712
open("base/17076/46168", O_RDWR)        = 13
lseek(13, 0, SEEK_END)                  = 188416
open("base/17076/46170", O_RDWR)        = 14
lseek(14, 0, SEEK_END)                  = 188416
mmap(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2b78c1b36000
brk(NULL)                               = 0x1007000
brk(0x102c000)                          = 0x102c000
brk(NULL)                               = 0x102c000
brk(NULL)                               = 0x102c000
brk(0x1025000)                          = 0x1025000
brk(NULL)                               = 0x1025000
lseek(12, 0, SEEK_END)                  = 7667712
open("pg_stat_tmp/pgss_query_texts.stat", O_RDWR|O_CREAT, 0600) = 15
pwrite64(15, "explain (analyze,buffers) select"..., 172, 93934) = 172
pwrite64(15, "\0", 1, 94106)            = 1
close(15)                               = 0
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\250\3\0\0\264B\0\0\10\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 936, 0, NULL, 0) = 936
sendto(8, "\2\0\0\0\10\1\0\0\264B\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 264, 0, NULL, 0) = 264
sendto(8, "\2\0\0\0\10\1\0\0\0\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 264, 0, NULL, 0) = 264
sendto(8, "\16\0\0\0H\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0"..., 72, 0, NULL, 0) = 72
sendto(9, "T\0\0\0#\0\1QUERY PLAN\0\0\0\0\0\0\0\0\0\0\31\377\377\377\377"..., 826, 0, NULL, 0) = 826
recvfrom(9, 0xd2b4e0, 8192, 0, NULL, NULL) = -1 EAGAIN (Resource temporarily unavailable)
epoll_wait(4,

虽然shared hit很多，但strace信息很少
strace显示会话只open了4个数据文件，通过fd和oid2name查到数据文件，分别是表、表的两个索引以及pathman_config：

From database "lzldb":
  Filenode                  Table Name
--------------------------------------
     46170  ix_name
     46168  pk_lzlinfo
     46160  lzlinfo
     16678  pathman_config

这些对象都不大，看上去不像这些表（or索引）过大导致的。

perf

（图不好贴自行脑补）
perf火焰图有40%的时间在heap_hot_search_buffer堆栈上

gdb

以heap_hot_search_buffe函数为依据，经过多次gdb，打如下断点试着看看哪有问题：

b relation_open
b get_relation_info
b RelationCacheInvalidateEntry 
b get_relname_relid
b AcceptInvalidationMessages
b RelationClearRelation
b pg_hint_plan_planner
b heap_hot_search_buffer

刚开始命中断点的时候，其实有很多无用的信息，因为他们是正常逻辑。不过后面发现，执行到一定程度，只有heap_hot_search_buffer命中：

Breakpoint 15, heap_hot_search_buffer (tid=tid@entry=0x2313c60, relation=0x2b2141663910, buffer=17045, snapshot=snapshot@entry=0x228a058, heapTuple=heapTuple@entry=0x23273d0, 
    all_dead=all_dead@entry=0x7ffce272e28f, first_call=true) at heapam.c:1503
1503    in heapam.c
(gdb) 
Continuing.
...

Breakpoint 15, heap_hot_search_buffer (tid=tid@entry=0x2313c60, relation=0x2b2141663910, buffer=96708, snapshot=snapshot@entry=0x228a058, heapTuple=heapTuple@entry=0x23273d0, 
    all_dead=all_dead@entry=0x7ffce272e28f, first_call=true) at heapam.c:1503
1503    in heapam.c

heap_hot_search_buffer传入的绝大部分参数没有变，包括relation、heapTuple的地址，只有buffer参数在改变，说明应该在扫描同一个relation。
heapTuple中包含table oid信息，直接打出来看看：

(gdb) p *heapTuple
$46 = {
  t_len = 968, 
  t_self = {
    ip_blkid = {
      bi_hi = 0, 
      bi_lo = 7211
    }, 
    ip_posid = 5
  }, 
  t_tableOid = 2619,   --这个比较有用
  t_data = 0x2b2155fced00

heap_hot_search_buffer传入的oid=2619，2619在pg_class中对应pg_statistic

select oid,relname from pg_class where oid in (2619)
  oid  |             relname              
-------+----------------------------------
  2619 | pg_statistic

找这个统计信息基表无可厚非，因为pg在生成可能的执行计划s时需要用到统计信息来估算代价。

pg_statistic的膨胀

定位到pg_statistic，那么看下pg_statistic表的情况

>  \dt+ pg_statistic
                                 List of relations
   Schema   |     Name     | Type  |  Owner   | Persistence |  Size   | Description 
------------+--------------+-------+----------+-------------+---------+-------------
 pg_catalog | pg_statistic | table | postgres | permanent   | 1036 MB | 


> select * from pg_class where relname='pg_statistic'\gx
-[ RECORD 1 ]-------+------------------------------------------------
oid                 | 2619
relname             | pg_statistic
relnamespace        | 11
reltype             | 12016
reloftype           | 0
relowner            | 10
relam               | 2
relfilenode         | 2619
reltablespace       | 0
relpages            | 132481
reltuples           | 4655

pg_statistic有1G，确实有些大了， 有132481块却只有4655行，这明显是有表膨胀了。但是即便有表膨胀，访问统计信息需要cache整个pg_statistic吗？逻辑上来说不需要，因为只需要访问对应表的统计信息就行了，实际上pg也是通过pg_statistic的主键索引pg_statistic_relid_att_inh_index来访问的。从下面的从堆栈中能看到传入的是pg_statistic的复合主键上的字段：

bt
...
#6  0x000000000086edbc in SearchCatCacheMiss (cache=cache@entry=0x226ba80, nkeys=nkeys@entry=3, hashValue=hashValue@entry=853716409, hashIndex=hashIndex@entry=57, v1=v1@entry=18767, v2=v2@entry=1, 
    v3=v3@entry=0, v4=v4@entry=0) at catcache.c:1368
#7  0x000000000086fa82 in SearchCatCacheInternal (v4=0, v3=<optimized out>, v2=<optimized out>, v1=<optimized out>, nkeys=3, cache=0x226ba80) at catcache.c:1299
#8  SearchCatCache3 (cache=0x226ba80, v1=v1@entry=18767, v2=v2@entry=1, v3=v3@entry=0) at catcache.c:1183
#9  0x0000000000880d70 in SearchSysCache3 (cacheId=cacheId@entry=58, key1=key1@entry=18767, key2=key2@entry=1, key3=key3@entry=0) at syscache.c:1145
#10 0x0000000000874092 in get_attavgwidth (relid=relid@entry=18767, attnum=1) at lsyscache.c:2991
#11 0x00000000006a2d46 in set_rel_width (root=root@entry=0x2326600, rel=rel@entry=0x21e8418) at costsize.c:5516 
...

传入了relid=relid@entry=18767, attnum=1

 select ctid,starelid,staattnum from pg_statistic where starelid=18767;
    ctid    | starelid | staattnum 
------------+----------+-----------
 (132657,6) |    18767 |         1
 (132657,7) |    18767 |         2
 (132657,8) |    18767 |         3
 (132657,9) |    18767 |         4
 (132658,1) |    18767 |         5
 (132658,2) |    18767 |         6
 (132658,3) |    18767 |         7
 (132658,4) |    18767 |         8
 (132658,5) |    18767 |         9
 (132658,6) |    18767 |        10
 --lzlinfo总共10个字段，每个字段对应一个staattnum

通过ctid可以看出，这些数据实际上只在2个块中。
看下通过复合主键索引访问pg_statistic，结果发现哪怕在只有2个块，也要访问1s，shared hit高达100w（1141568）：

 explain (analyze,buffers,timing,verbose) select ctid,starelid from pg_statistic where starelid=18767;
                                                                             QUERY PLAN                                                                             
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using pg_statistic_relid_att_inh_index on pg_catalog.pg_statistic  (cost=0.41..103.31 rows=23 width=10) (actual time=105.416..1035.723 rows=10 loops=1)
   Output: ctid, starelid
   Index Cond: (pg_statistic.starelid = '18767'::oid)
   Buffers: shared hit=1141568  --异常
 Planning:
   Buffers: shared hit=8
 Planning Time: 0.102 ms
 Execution Time: 1035.802 ms

通过索引访问10条pg_statistic数据，shared hit有100w，跟SQL的100w planning shared hit差不多。（注意这里的 Planning Time很少，说明我们没有在生成执行计划阶段出问题）

索引dead tuple

如果vacuum没有真的“跑起来”，那么索引的dead tuple还是会指向死元组
参考从很慢的唯一索引扫描到索引膨胀
image.png

autovacuum未回收死元组

表膨胀这么大，autovacuum不应该回收吗？

select * from pg_stat_all_tables where relname='pg_statistic'\gx
-[ RECORD 1 ]-------+------------------------------
relid               | 2619
schemaname          | pg_catalog
relname             | pg_statistic
seq_scan            | 1  	    --顺序访问pg_statistic极少
seq_tup_read        | 4655
idx_scan            | 28715508  --索引访问pg_statistic多
idx_tup_fetch       | 25150245
n_tup_ins           | 46
n_tup_upd           | 1292143   --update很多
n_tup_del           | 14
n_tup_hot_upd       | 138448
n_live_tup          | 4655
n_dead_tup          | 1496776
n_mod_since_analyze | 1292203
n_ins_since_vacuum  | 0
last_vacuum         | [null]
last_autovacuum     | 2024-08-16 20:34:15.045022+08  --注意autovacuum的时间是一个最近的值
last_analyze        | [null]
last_autoanalyze    | [null]
vacuum_count        | 0
autovacuum_count    | 144170
analyze_count       | 0
autoanalyze_count   | 0

其实pg_statistic上是autovacuum一直在跑，只不过进程有可能看不到，因为autovacuum没有跑什么，所以跑的比较快，跑完又snap休息了

show autovacuum_naptime ;
 autovacuum_naptime 
--------------------
 1min

每间隔1分钟休息一次，日志中也是每隔1分钟打印一次autovacuum信息。

2024-08-16 21:05:15.267 CST,,,41080,,66bf4e87.a078,1,,2024-08-16 21:05:11 CST,27/166839,0,LOG,00000,"automatic vacuum of table ""lzldb.pg_catalog.pg_statistic"": index scans: 0
pages: 0 removed, 132685 remain, 1 skipped due to pins, 0 skipped frozen
tuples: 0 removed, 1501745 remain, 1497090 are dead but not yet removable, oldest xmin: 119329380
buffer usage: 265443 hits, 0 misses, 0 dirtied
avg read rate: 0.000 MB/s, avg write rate: 0.000 MB/s
system usage: CPU: user: 0.53 s, system: 0.17 s, elapsed: 3.38 s
WAL usage: 1 records, 0 full page images, 233 bytes",,,,,,,,,"","autovacuum worker"
2024-08-16 21:05:17.474 CST,,,41080,,66bf4e87.a078,2,,2024-08-16 21:05:11 CST,27/166844,136438968,LOG,00000,"automatic analyze of table ""lzldb.public.lzlinfo"" system usage: CPU: user: 2.02 s, system: 0.00 s, elapsed: 2.08 s",,,,,,,,,"","autovacuum worker"
"

1497090 are dead but not yet removable虽然触发了autovacuum但是根本没有回收到死元组，1497090条死元组没有清理。
排查下库内是谁持有了oldest xmin: 119329380，很快可以定位到复制槽：

select * from pg_replication_slots;
    slot_name    |  plugin  | slot_type | datoid | database | temporary | active | active_pid |  xmin  | catalog_xmin | restart_lsn  | confirmed_flush_lsn | wal_status | safe_wal_size 
-----------------+----------+-----------+--------+----------+-----------+--------+------------+--------+--------------+--------------+---------------------+------------+---------------
 slotslotlostname | pgoutput | logical   |  17076 | lzldb   | f         | f      |     [null] | [null] |    119329380 | 3F9/105A4970 | 3F9/105F8778        | extended   |        [null]

slot的catalog_xmin=119329380，与vacuum展示的oldest xmin: 119329380一致。
active=f说明复制链路已经挂了。

修复问题

把复制槽删除：

select pg_drop_replication_slot('slotslotlostname');
 pg_drop_replication_slot 
--------------------------

手动vacuum或再等待1分钟autovacuum。
最后再开一个全新的会话测试一下恢复没有：

# psql
psql (13.2)
Type "help" for help.

> \c lzldb
You are now connected to database "lzldb" as user "postgres".
> explain (analyze,buffers,timing) select * from  lzlinfo limit 1;
                                                     QUERY PLAN                                                      
---------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.00..8.04 rows=1 width=71) (actual time=0.023..0.025 rows=1 loops=1)
   Buffers: shared hit=1
   ->  Seq Scan on lzlinfo  (cost=0.00..3802.73 rows=473 width=71) (actual time=0.018..0.018 rows=1 loops=1)
         Buffers: shared hit=1
 Planning:
   Buffers: shared hit=2578
 Planning Time: 9.605 ms
 Execution Time: 0.098 ms

耗时从1s下降到10ms，Planning shared hit从100w下降到2k，问题基本解决。

案例总结

复制链路挂掉，复制槽未及时清理，导致pg_statistic统计信息基表膨胀，导致每个backend在首次加载统计信息时都非常缓慢且读取多余的page到本地缓存，导致每个backend的缓存都大于正常水平（2g左右），多个backend导致最后的OOM。
其实问题很简单，只是过程比较曲折···简言之：基表pg_statistic膨胀导致执行计划生成阶段访问数据过大。元数据基表膨胀其实还有其他棘手的问题，有缘再见了。

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

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

学习C语言 第十九天

学习C语言 第十九天

第一项 C 内存管理 内存是通过指针变量来管理的。通过一些函数和运算符&#xff0c;可以对内存进行操作&#xff0c;包括分配、释放、移动和复制等。 序号函数和描述1void *calloc(int num, int size); 在内存中动态地分配 num 个长度为 size 的连续空间&#xff0c;并将每一…
阅读更多...
【安全靶场】-DC-7

【安全靶场】-DC-7

❤️博客主页&#xff1a; iknow181 &#x1f525;系列专栏&#xff1a; 网络安全、 Python、JavaSE、JavaWeb、CCNP &#x1f389;欢迎大家点赞&#x1f44d;收藏⭐评论✍ 一、收集信息 1.查看主机是否存活 nmap -T4 -sP 192.168.216.149 2.主动扫描 看开放了哪些端口和功能 n…
阅读更多...
企业差旅报销管理：如何管控差旅成本?

企业差旅报销管理：如何管控差旅成本?

如何高效地管理和控制差旅成本,是每个企业财务部门都要面对的重要课题。作为一体化差旅报销管理平台,分贝通提供了从事前、事中到事后的全流程差旅费控方案,帮助企业实现精细化管理和成本控制。本文将详细介绍分贝通如何通过其全流程差旅费控方案帮助企业管控差旅成本,提升管理…
阅读更多...
Ansible初识

Ansible初识

ansible初识 Ansible是一种自动化工具&#xff0c;用于配置管理、应用程序部署和任务自动化。它基于Python语言开发&#xff0c;使用SSH协议进行通信&#xff0c;并且不需要在被管理的主机上安装任何客户端。Ansible使用简单的YAML语言来描述任务和配置&#xff0c;使得操作简…
阅读更多...
ROS2 入门控制命令（以海龟为例）和工作空间介绍

ROS2 入门控制命令（以海龟为例）和工作空间介绍

目录 前言1 打开海龟显示窗口2 启用键盘控制窗口3 海龟按圆形轨迹运动&#xff08;圆周运动&#xff09;4 产生新的海龟5 记录并播放海龟运动轨迹ros2 bag 功能5.1 记录5.2 播放 ROS的工作空间6 创建功能包7 编译功能包 前言 命令方向特别注意空格&#xff0c;冒号后面加空格要…
阅读更多...
力扣 | 子数组滑动窗口 | 560. 和为 K 的子数组、209. 长度最小的子数组、862. 和至少为 K的最短子数组、220. 存在重复元素 III

力扣 | 子数组滑动窗口 | 560. 和为 K 的子数组、209. 长度最小的子数组、862. 和至少为 K的最短子数组、220. 存在重复元素 III

文章目录 一、非滑动窗口1.1 560/LCR 010. 和为 K 的子数组1.2 862. 和至少为 K 的最短子数组 二、滑动窗口2.1 209/LCR 008. 长度最小的子数组2.2 220. 存在重复元素 III 下面的题并不是全都由滑动窗口解决&#xff0c;有的题可以&#xff0c;有的题不可以&#xff0c;放入滑动…
阅读更多...
《黑神话：悟空》Steam峰值超200万 国内玩家占9成

《黑神话：悟空》Steam峰值超200万 国内玩家占9成

《黑神话&#xff1a;悟空》自今天白天上午10点解锁以来&#xff0c;Steam在线峰值不断创新高&#xff0c;白天创下的140万记录又被晚上超过。据SteamDB统计&#xff0c;随着更多“打工人”回家休息&#xff0c;《黑神话&#xff1a;悟空》Steam同时在线已经突破了200万&#x…
阅读更多...
编程之旅：从挫折到突破的心路历程

编程之旅：从挫折到突破的心路历程

你是如何克服编程学习中的挫折感的&#xff1f; 编程学习之路上&#xff0c;挫折感就像一道道难以逾越的高墙&#xff0c;让许多人望而却步。然而&#xff0c;真正的编程高手都曾在这条路上跌倒过、迷茫过&#xff0c;却最终找到了突破的方法。你是如何在Bug的迷宫中找到出口的…
阅读更多...
软件产品测试报告内容简析，第三方软件测试公司测试服务分享

软件产品测试报告内容简析，第三方软件测试公司测试服务分享

在数字化快速发展的今天&#xff0c;软件产品的质量直接影响着企业的竞争力与市场表现&#xff0c;软件产品测试报告作为整个测试过程的总结性文档至关重要。 一、软件产品测试报告 　　软件产品测试报告是测试团队对软件系统的质量评估和诊断的重要文件&#xff0c;它包含了对…
阅读更多...
LabVIEW滚动轴承故障诊断系统

LabVIEW滚动轴承故障诊断系统

滚动轴承是多种机械设备中的关键组件&#xff0c;其性能直接影响整个机械系统的稳定性和安全性。由于轴承在运行过程中可能会遇到多种复杂的工作条件和环境因素影响&#xff0c;这就需要一种高效、准确的故障诊断方法来确保机械系统的可靠运行。利用LabVIEW开发的故障诊断系统&…
阅读更多...
VMwareWorkstation安装ESXi 7.0U3系统详细教程

VMwareWorkstation安装ESXi 7.0U3系统详细教程

版本信息 VMwareWorkstation版本如下&#xff1a; ESXI系统镜像版本如下&#xff1a; 安装步骤 ESXi虚拟机硬件配置 选择创建新的虚拟机 选择自定义&#xff0c;点击下一步 选择ESXi 7.0&#xff0c;点击下一步 选择稍后安装操作系统&#xff0c;点击下一步 按照图下所示选择…
阅读更多...
十个方面100个网络安全相关知识点，快来学习！（上）

十个方面100个网络安全相关知识点，快来学习！（上）

网络安全风险无处不在&#xff0c;现梳理了100个网络安全相关的小知识&#xff0c;希望能进一步提升大家的安全意识&#xff0c;帮助大家建立更加安全的网络环境。 一、账号密码安全 1. 如果有初始密码&#xff0c;应尽快修改。 2. 密码长度不少于8个字符。 3. 不要使用单一…
阅读更多...
从零开始的nginx学习世界

从零开始的nginx学习世界

一&#xff1a;nginx概述 1.1 nginx是什么 1&#xff1a;Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器&#xff0c;同时也提供了IMAP/POP3/SMTP服务。Nginx是由伊戈尔赛索耶夫为俄罗斯访问量第二的Rambler.ru站点&#xff08;俄文&#xff1a;Рамблер&…
阅读更多...
Linux ubuntu 24.04 运行《文明5》游戏，解决游戏中文设置的问题！

Linux ubuntu 24.04 运行《文明5》游戏，解决游戏中文设置的问题！

Linux ubuntu 24.04 运行《文明5》游戏&#xff0c;解决游戏中文设置的问题&#xff01; 《文明5》是一款回合制经营策略游戏&#xff0c;拼的就是科技发展速度&#xff0c;点的是科技树&#xff0c;抢的就是科技制高点&#xff0c;但是真的是时间漫长&#xff0c;可能需要好几…
阅读更多...
解密高可靠分布式锁：优化策略与技术实现指南

解密高可靠分布式锁：优化策略与技术实现指南

随着系统架构逐渐从单机走向分布式&#xff0c;如何在分布式环境下保证线程同步执行成为一个不可忽视的问题。分布式锁作为解决这一问题的关键技术&#xff0c;为分布式系统中的资源共享和任务协调提供了重要支持。选择合适的分布式锁实现方式&#xff0c;可以有效提高系统的可…
阅读更多...
重塑“上海我店模式”的创新生态与绿色消费浪潮

重塑“上海我店模式”的创新生态与绿色消费浪潮

在数字经济的浪潮中&#xff0c;一个名为“上海我店模式”的平台迅速崛起&#xff0c;短短三年内便实现了流水破百亿的壮举。该平台巧妙地将绿色消费积分机制融入本地生活与异业联盟商圈&#xff0c;不仅激活了庞大的私域流量&#xff0c;更以其独特的商业模式引领了消费新风尚…
阅读更多...
hyper-v ubuntu下连接嵌入式linux板卡

hyper-v ubuntu下连接嵌入式linux板卡

用hyper-v非常的方便&#xff0c;不用装vm也不会那么臃肿&#xff0c;但如何在hyper-v和嵌入式板卡之间进行通讯呢&#xff1f; 1.环境 采用的是100ask-imx6ull板卡&#xff0c;hyper-v装的是ubuntu22系统。 hyper-v根据文章hyper-v上外网已经配置了一个虚拟网卡。 2.物理连…
阅读更多...
vue2 proxy 代理配置报错 ValidationError: webpack Dev Server Invalid Options

vue2 proxy 代理配置报错 ValidationError: webpack Dev Server Invalid Options

vue/cli3&#xff08;本文实际使用的是vue/cli4&#xff09;代理配置如下&#xff1a; vue/cli4使用vue/cli3的代理配置会出现异常&#xff0c;本文解决办法为解决方法二处理&#xff0c;运行正常。 vue 启动项目 yarn serve 或者 npm run dev 或者 npm run serve 时&#x…
阅读更多...
and design vue表格列宽度拖拽，vue-draggable-resizable插件使用

and design vue表格列宽度拖拽，vue-draggable-resizable插件使用

and design vue2版的table表格不能拖拽列的宽度&#xff0c;通过vue-draggable-resizable插件实现 我用的是and design 1.7.8的版本&#xff0c;先下插件 yarn add vue-draggable-resizable2.1.0我这版本的and design用最新3.0.0以上的插件会有问题&#xff0c;实现不了效果&a…
阅读更多...
EmguCV学习笔记 VB.Net 5.3 透视变换

EmguCV学习笔记 VB.Net 5.3 透视变换

版权声明&#xff1a;本文为博主原创文章&#xff0c;转载请在显著位置标明本文出处以及作者网名&#xff0c;未经作者允许不得用于商业目的。 EmguCV是一个基于OpenCV的开源免费的跨平台计算机视觉库,它向C#和VB.NET开发者提供了OpenCV库的大部分功能。 教程VB.net版本请访问…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023