利用 Redis 查看系统资源占用情况
Redis是一种开源的高性能Key-Value存储系统，由于其卓越的性能和可靠性，已经被广泛应用于互联网应用中。
除了作为缓存系统之外，Redis还可以用于监控系统资源的占用情况。通过利用Redis提供的一些命令，可以轻松地查看当前系统的CPU、内存、磁盘等资源的使用情况。
在Linux系统下，可以使用如下命令来安装Redis：
sudo apt-get install redis-server
安装完成之后，可以通过redis-cli命令进入Redis命令行界面。
进入Redis命令行界面后，可以使用如下命令查看当前Redis实例的一些基本信息：
127.0.0.1:6379> INFO# Serverredis_version:6.2.3redis_git_sha1:00000000redis_git_dirty:0redis_build_id:066a8018c79b9d54redis_mode:standaloneos:Linux 5.11.0-27-generic x86_64arch_bits:64multiplexing_api:epollatomicvar_api:atomic-builtingcc_version:9.3.0process_id:18919run_id:fb9fd38bca6d81ffb775c1141552e2b91943ef96TCP_port:6379uptime_in_seconds:11696uptime_in_days:0hz:10configured_hz:10lru_clock:20003794executable:/usr/bin/redis-serverconfig_file:# Clientsconnected_clients:1client_recent_max_input_buffer:2client_recent_max_output_buffer:0blocked_clients:0# Memoryused_memory:157848888used_memory_human:150.49Mused_memory_rss:171810560used_memory_peak:171139496used_memory_peak_human:163.16Mused_memory_peak_perc:92.24%used_memory_overhead:6217099used_memory_startup:1578152used_memory_dataset:151632789used_memory_dataset_perc:96.07%allocator_allocated:157848888allocator_active:162310912allocator_resident:876027136total_system_memory:2005565952total_system_memory_human:1.87Gused_memory_lua:6144used_memory_lua_human:6.00Kused_memory_scripts:0used_memory_scripts_human:0Bnumber_of_cached_scripts:0maxmemory:0maxmemory_human:0Bmaxmemory_policy:noevictionallocator_frag_ratio:1.03allocator_frag_bytes:4466072allocator_rss_ratio:5.39allocator_rss_bytes:713716224rss_overhead_ratio:0.20rss_overhead_bytes:-70421632mem_fragmentation_ratio:1.09mem_fragmentation_bytes:13962672mem_not_counted_for_evict:0mem_replication_backlog:0mem_clients_slaves:0mem_clients_normal:1mem_aof_buffer:0mem_allocator:jemalloc-5.2.1# Persistenceloading:0rdb_changes_since_last_save:4rdb_bgsave_in_progress:0rdb_last_save_time:1640458723rdb_last_bgsave_status:okrdb_last_bgsave_time_sec:0rdb_current_bgsave_time_sec:-1rdb_last_cow_size:2097152aof_enabled:0aof_rewrite_in_progress:0aof_rewrite_scheduled:0aof_last_rewrite_time_sec:-1aof_current_rewrite_time_sec:-1aof_last_bgrewrite_status:okaof_last_write_status:okaof_last_cow_size:0# Statstotal_connections_received:53total_commands_processed:60instantaneous_ops_per_sec:0total_net_input_bytes:10331total_net_output_bytes:85536instantaneous_input_kbps:0.00instantaneous_output_kbps:0.00rejected_connections:0sync_full:0sync_partial_ok:0sync_partial_err:0expired_keys:0evicted_keys:0keyspace_hits:0keyspace_misses:0pubsub_channels:0pubsub_patterns:0latest_fork_usec:1946migrate_cached_sockets:0# Replicationrole:masterconnected_slaves:0master_replid:24c4f4cf08ef9924a461891138020bc66b063ca5master_replid2:0000000000000000000000000000000000000000master_repl_offset:0second_repl_offset:-1repl_backlog_active:0repl_backlog_size:1048576repl_backlog_first_byte_offset:0repl_backlog_histlen:0# CPUused_cpu_sys:66.649558used_cpu_user:10.144010used_cpu_sys_children:0.060000used_cpu_user_children:0.060000# Commandstatscmdstat_info:calls=1,usec=0,usec_per_call=0.00cmdstat_monitor:calls=53,usec=47295,usec_per_call=891.60cmdstat_role:calls=1,usec=398,usec_per_call=398.00# Clustercluster_enabled:0# Keyspace
其中，上述命令会返回如下Redis实例的基本信息：
– Server：返回Redis 服务器 的基本信息，包括版本、Git Commit哈希值、编译ID、运行模式、操作系统、架构、多路复用API、原子变量API、GCC版本、PID、运行ID、TCP端口、已经运行的时间、频率（即每秒执行检查键空间环节的次数）、已配置的频率、LRU时钟、可执行的程序、配置文件等；
– Clients：返回Redis的客户端信息，包括当前连接的客户端数、客户端输入缓冲区的最大值、客户端输出缓冲区的最大值、被阻塞的客户端数；
– Memory：返回Redis实例使用的内存信息，包括已使用的内存、已使用的内存（人类可读格式）、正在使用的RSS（Resident Set Size在RAM中的部分）、最大的内存使用量历史峰值、最大的内存占路用率历史峰值、当前内存使用的下属空间（-overhead）、Redis启动后分配的内存、真正存储键值对的数据结构使用的内存、内存碎片率、内存碎片大小、操作系统没有计数的内存、复制操作用的缓冲区、Slaves和Clients占用的内存（用于在Info命令中显示）；
– Persistence：返回持久化相关的信息，包括RDB（Redis数据库文件）持久化的相关信息，AOF（Append-only file，即Redis的追加日志文件）持久化的相关信息；
– Stats：返回统计信息，包括Redis服务器接收的总连接数、Redis服务器执行的总命令数、Redis服务器执行的瞬时操作数、Redis服务器接收到的总字节数、Redis服务器发送的总字节数、Redis服务器瞬时接收数据的速率、Redis服务器瞬时发送数据的速率、拒绝连接的客户端的总数、同步操作相关的统计、过期键和失效键的数量、命中的和未命中的键数、通过PUB / SUB收听的通道和模式的数量、最近一次成功执行FORK（）函数的耗时、迁移工具中缓存的套接字数等；
– Replication：返回复制相关的信息，包括Redis服务器的角色（主服务器/从服务器）、连接到当前服务器的从服务器的数量、主服务器的复制ID、从服务器的复制ID、主库的复制偏移量、从库的复制偏移量、正在使用复制缓冲区的状态、复制缓冲区的大小、复制缓冲区中第一个字节的偏移量、复制缓冲区历史长度等；
– CPU：返回Redis服务器的CPU占用情况，包括Redis服务器在内核模式下花费的CPU时间、Redis服务器在用户模式下花费的CPU时间；
– Commandstats：返回Redis实例中执行Redis
香港服务器首选树叶云，2H2G首月10元开通。树叶云（shuyeidc.com）提供简单好用，价格厚道的香港/美国云服务器和独立服务器。IDC+ISP+ICP资质。ARIN和APNIC会员。成熟技术团队15年行业经验。
linux 怎么读取cpu功耗
获取CPU使用率1实时CPU使用率 类似任务管理器实时系统信息可以通过top命令查看。 显示的信息四个参数分别是：用户的模式（user）、低优先级的用户模式（nice）、系统内核模式（system）以及系统空闲的处理器时间（idle）2查看CPU处理器使用率对于CPU使用率一般都是通过CPU使用情况，查看/proc/stat cpu状态文件3平均CPU使用率对于一般某时间段CPU的使用率来说，可以通过查看/pRoc/loadavg 文件信息4第三方监控软件查看网上有很多网管，监控软件安装配置好之后。 可以通过网页管理查看CPU等硬件情况和CPU使用率，负载等参数END其它相关信息内存使用率 查看 /proc/meminfo查看内存详细信息，也可以通过free 命令查看网络利用率 通过查看文件/proc/net/dev 可以了解，CentOS系统的网络使用情况跟windows的网络情况类似
Linux进程查看
[例18] 查看登录用户的详细情况，键入：$ who -uH显示如下：USER LINE LOGIN-TIME IDLE FROMroot tty1 Mar 17 13:49 . foxy tty2 Mar 17 13:49 00:01 root tty3 Mar 17 13:49 00:01bbs ttyp0 Mar 17 13:49 00:01 （） 这样一目了然。 其中-u选项指定显示用户空闲时间，所以可以看到多了一项IDLE。 第一个root用户的IDLE项是一个“.”，这就说明该用户在前1秒仍然是活动的，而其他用户后面都有一个时间，称为空闲时间。 最后来看看使用“who am i”格式命令的结果!root tty1 Mar 17 13:49可见只显示出了运行该who命令的用户情况，当然这时候不存在空闲时间。 who命令应用起来非常简单，可以比较准确地掌握用户的情况，所以使用非常广泛。 w命令该命令也用于显示登录到系统的用户情况，但是与who不同的是，w命令功能更加强大，它不但可以显示有谁登录到系统，还可以显示出这些用户当前正在进行的工作，并且统计数据相对who命令来说更加详细和科学，可以认为w命令就是who命令的一个增强版。 w命令的显示项目按以下顺序排列：当前时间，系统启动到现在的时间，登录用户的数目，系统在最近1秒、5秒和15秒的平均负载。 然后是每个用户的各项数据，项目显示顺序如下：登录帐号、终端名称、远程主机名、登录时间、空闲时间、JCPU、PCPU、当前正在运行进程的命令行。 其中JCPU时间指的是和该终端（tty）连接的所有进程占用的时间。 这个时间里并不包括过去的后台作业时间，但却包括当前正在运行的后台作业所占用的时间。 而PCPU时间则是指当前进程（即在WHAT项中显示的进程）所占用的时间。 下面介绍该命令的具体用法和参数。 语法格式如下：w -[husfV] [user] 下面对参数进行说明：-h 不显示标题。 -u 当列出当前进程和CPU时间时忽略用户名。 这主要是用于执行su命令后的情况。 -s 使用短模式。 不显示登录时间、JCPU和PCPU时间。 -f 切换显示FROM项，也就是远程主机名项。 默认值是不显示远程主机名，当然系统管理员可以对源文件作一些修改使得显示该项成为默认值。 -V 显示版本信息。 User 只显示指定用户的相关情况。 [例19] 显示当前登录到系统的用户的详细情况$ w 2:50pm up 2 min， 4 users， load average:0.22，0.16，0.06USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root tty1 2:49pm 0:00s 0.56s 0.10s wfoxy tty2 2:49pm 1:09 0.42s 0.42s bashroot tty3 2:49pm 46.00s 0.67s 0.25s telnet bbs3 bbs ttyp0 2:49pm 45.00s 0.49s 0.49s bbs h
memcached和redis的区别
medis与Memcached的区别传统MySQL+ Memcached架构遇到的问题 实际MySQL是适合进行海量数据存储的，通过Memcached将热点数据加载到cache，加速访问，很多公司都曾经使用过这样的架构，但随着业务数据量的不断增加，和访问量的持续增长，我们遇到了很多问题： 需要不断进行拆库拆表，Memcached也需不断跟着扩容，扩容和维护工作占据大量开发时间。 与mysql数据库数据一致性问题。 数据命中率低或down机，大量访问直接穿透到DB，MySQL无法支撑。 4.跨机房cache同步问题。 众多NoSQL百花齐放，如何选择 最近几年，业界不断涌现出很多各种各样的NoSQL产品，那么如何才能正确地使用好这些产品，最大化地发挥其长处，是我们需要深入研究和思考的问题，实际归根结底最重要的是了解这些产品的定位，并且了解到每款产品的tradeoffs，在实际应用中做到扬长避短，总体上这些NoSQL主要用于解决以下几种问题 1.少量数据存储，高速读写访问。 此类产品通过数据全部in-momery 的方式来保证高速访问，同时提供数据落地的功能，实际这正是Redis最主要的适用场景。 2.海量数据存储，分布式系统支持，数据一致性保证，方便的集群节点添加/删除。 3.这方面最具代表性的是dynamo和bigtable 2篇论文所阐述的思路。 前者是一个完全无中心的设计，节点之间通过gossip方式传递集群信息，数据保证最终一致性，后者是一个中心化的方案设计，通过类似一个分布式锁服务来保证强一致性,数据写入先写内存和redo log，然后定期compat归并到磁盘上，将随机写优化为顺序写，提高写入性能。 free，auto-sharding等。 比如目前常见的一些文档数据库都是支持schema-free的，直接存储json格式数据，并且支持auto-sharding等功能，比如mongodb。 面对这些不同类型的NoSQL产品,我们需要根据我们的业务场景选择最合适的产品。 Redis适用场景，如何正确的使用 前面已经分析过，Redis最适合所有数据in-momory的场景，虽然Redis也提供持久化功能，但实际更多的是一个disk-backed的功能，跟传统意义上的持久化有比较大的差别，那么可能大家就会有疑问，似乎Redis更像一个加强版的Memcached，那么何时使用Memcached,何时使用Redis呢?如果简单地比较Redis与Memcached的区别，大多数都会得到以下观点： 1Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 2Redis支持数据的备份，即master-slave模式的数据备份。 3Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。 抛开这些，可以深入到Redis内部构造去观察更加本质的区别，理解Redis的设计。 在Redis中，并不是所有的数据都一直存储在内存中的。 这是和Memcached相比一个最大的区别。 Redis只会缓存所有的 key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(size_in_memory)”计 算出哪些key对应的value需要swap到磁盘。 然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。 这种特性使得Redis可以 保持超过其机器本身内存大小的数据。 当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。 同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改。 使用Redis特有内存模型前后的情况对比： VM off: 300k keys, 4096 bytes values: 1.3G used VM on:300k keys, 4096 bytes values: 73M used VM off: 1 million keys, 256 bytes values: 430.12M used VM on:1 million keys, 256 bytes values: 160.09M used VM on:1 million keys, values as large as you want, still: 160.09M used当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。 在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。 这种策略在客户端的数量较小，进行 批量操作的时候比较合适。 但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。 所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间。 如果希望在海量数据的环境中使用好Redis，我相信理解Redis的内存设计和阻塞的情况是不可缺少的。
发表评论