搜索[performance]结果-低调大师优秀个人博客

精选列表

搜索[performance]，共2517篇文章

西门子推出Omneo Performance Analytics 提供大数据分析服务

ZDNet至顶网软件频道消息：西门子近日宣布推出Omneo Performance Analytics（PA）解决方案。

2017-08-20

高性能服务器架构的几个注意点 (High-Performance Server Architecture)

High-Performance Server Architecture 高性能服务器架构来源：http://pl.atyp.us/content/tech/servers.html译文来源：http

2018-03-10

Java并发编程实战系列11之性能与可伸缩性Performance and Scalability

线程可以充分发挥系统的处理能力，提高资源利用率。同时现有的线程可以提升系统响应性。但是在安全性与极限性能上，我们首先需要保证的是安全性。 11.1 对性能的思考提升性能=用更少的资源做更多的事情（太对了，这才是问题的本质）。资源包括：CPU时钟周期，内存，网络带宽，I/O带宽，数据请求，磁盘空间等。资源密集型说的就是对上述维度敏感的应用。与单线程相比，多线程总会一起一些额外的性能开销：线程协调with coordinating between threads (locking, signaling, and memory synchronization) 上下文切换increased context switching 线程创建和销毁thread creation and teardown 线程调度scheduling overhead 可伸缩性是指：增加资源，程序的吞吐可以成比例的增加。性能的提高往往是一个权衡的过程，需要考虑诸多因素。 11.2 Amdahl定律 Amdahl's Law 收割可以靠并行提高性能，而作物生长则不行。这是一个很简单的自然界的问题，在计算机界也存在，需要对问题进行合理的分解，发现潜在的并行能力。 Amdahl定律：并行计算中的加速比是用并行前的执行速度和并行后的执行速度之比来表示的，它表示了在并行化之后的效率提升情况。 speedup <= 1 / F + (1 - F) /N F表示被串行化的部分，N表示处理器数量。如果N无穷大，那么最大的加速比例是1/F。理论上如果50%是串行的，那么最大的加速比只能是2。如果10%串行。那么最大加速比接近10，如果N=10也就是说有10个处理器资源，那么最高的加速比是5.4，在100个处理器的情况下是9.2。但是任何程序都存在串行部分，例如从队列中take数据，访问数据库的操作等，这是绝对的。书中举了一个例子是Synchronized linkedlist和ConcurrentLinkedQueue的吞吐率对比，在处理器数量到达上限后，他们的吞吐都基本是一条持平的线，但是Synchronized linkedlist吞吐率更低，在处理器较少的情况下就到达了极限，这主要受context switch的限制。 11.3 线程引入的开销单线程不存在线程调度，也不存在同步开销，不需要使用锁来保证安全一致性。而多线程这些都需要考虑。 11.3.1 上下文切换操作系统的设计者巧妙地利用了时间片轮转的方式, CPU给每个任务都服务一定的时间, 然后把当前任务的状态保存下来, 在加载下一任务的状态后, 继续服务下一任务. 如果可运行的线程数大于CPU数量，那么OS会最终将某个正在运行的线程调度出来，从而让其他线程能够使用CPU，这会导致一次上下文切换，主要包括当前线程“保存现场”，并且新调度出来的线程需要“恢复现场“。这里的context switch直接消耗包括: CPU寄存器需要保存和加载, 系统调度器的代码需要执行, TLB实例需要重新加载, CPU 的pipeline需要刷掉; 间接消耗指的是多核的cache之间得共享数据, 间接消耗对于程序的影响要看线程工作区操作数据的大小). JVM和OS消耗的CPU时钟周期越少，那么APP可用的CPU时钟周期就越多。往往OS有一个最小的执行时间，防止过于频繁的上下文切换。 JVM会因为阻塞比如锁、阻塞I/O而挂起线程，如果频繁的阻塞，就会无法使用完整的调度时间片。//? 如果可运行的线程数大于CPU的内核数，那么OS会根据一定的调度算法，强行切换正在运行的线程，从而使其它线程能够使用CPU周期。切换线程会导致上下文切换。线程的调度会导致CPU需要在操作系统和进程间花费更多的时间片段，这样真正执行应用程序的时间就减少了。另外上下文切换也会导致缓存的频繁进出，对于一个刚被切换的线程来说，可能由于高速缓冲中没有数据而变得更慢，从而导致更多的IO开销。 vmstat 命令可以看cs这一个字段看上下文切换的数据。 11.3.2 内存同步同步的性能开销包括多个方面。在synchronized和volatile提供的可见性保证中会使用一些特殊指令，即内存栅栏（memory barrier），内存栅栏可以刷新缓存，满足可见性，但是它也会抑制一些编译器优化，例如不能指令重排序。现代的JVM对于无竞争的synchronized的消耗非常小，基本微乎其微。同时现代的JVM编译优化做的非常成熟，一些不必要的同步开销往往可以优化掉。例如，下面的代码会去掉锁获取。 synchronized (new Object()) { // do something } 还有一些比如escape analysis会找出不会发布到堆上的本地对象，锁的获取和释放会被优化为最小的次数甚至去掉。例如下面的操作。 public String getStoogeNames() { List<String> stooges = new Vector<String>(); stooges.add("Moe"); stooges.add("Larry"); stooges.add("Curly"); return stooges.toString(); } 当然即使不escape，也会有lock coarsening过程，将临近的同步代码块使用同一个锁合并起来。这都减少了同步的开销。所以不必过度担心非竞争同步带来的开销，这个基本的机制已经非常的快了，而且JVM还有能进行额外的优化以进一步降低或者消除开销的本领。不同线程间要进行数据同步，synchronized以及volatile提供的可见性都会导致缓存失效。线程栈之间的数据要和主存进行同步，这些同步有一些小小的开销。如果线程间同时要进行数据同步，那么这些同步的线程可能都会受阻。 11.3.3 阻塞竞争的同步需要OS介入，从而增加了开销。当在锁上发生竞争时，失败者线程会被阻塞，JVM在实现发现阻塞的行为时，可以采用自旋等待 spin-waiting 或者OS挂起被阻塞的线程这两种的效率高低取决于上下文切换的开销以及成功获取锁之前的等待时间，如果等待时间较短，则spin-waiting，如果较长则挂起。一个线程被阻塞会产生上下文切换的影响，但是它到底何时执行这是由OS决定的，靠时间分片机制，这个调度的策略是OS解决的，而JVM的scheduler解决的是阻塞释放锁之后哪个线程需要被select出来执行，也就是转到runnable状态。 There is no single Java Virtual Machine; JVM is a specification, and there are multiple implementations of it, including the OpenJDK version and the Sun version of it, among others. I don't know for certain, but I would guess that any reasonable JVM would simply use the underlying threading mechanism provided by the OS, which would imply POSIX Threads (pthreads) on UNIX (Mac OS X, Linux, etc.) and would imply WIN32 threads on Windows. Typically, those systems use a round-robin strategy by default. Many types of algorithms exist like preemptive and time slicingwith round robin etc. The JVM is based on preemptive and priority based scheduling algorithm to select thread to run. 每个Java线程一对一映射到Solaris平台上的一个本地线程上，并将线程调度交由本地线程的调度程序。由于Java线程是与本地线程是一对一地绑在一起的，所以改变Java线程的优先权也不会有可靠地运行结果。对于类Unix系统而言，一般都是进程作为任务的调度单位，也即是操作系统调度器，只会针对进程来分配CPU等资源。由于进程彼此独立，相互不可进行直接访问，这增加了应用的通信成本。所以后面有了微进程，微进程与进程不同的是，允许一定程度上，彼此可以直接进行访问，详细可参考LinuxThreads。JVM在一些类Unix平台下，就是将线程映射到操作系统的微进程，来实现线程调度。这样多线程能够直接被系统调度器进行调度，与此对应的就是其线程的创建和销毁的成本就比较高，而且JVM的线程优先级很难进行匹配，无法提供确切的保证，仅仅是个hint。当发生锁竞争时，失败的线程会导致阻塞。通常阻塞的线程可能在JVM内部进行自旋等待，或者被操作系统挂起。自旋等待可能会导致更多的CPU切片浪费，而操作系统挂起则会导致更多的上下文切换。 11.4 减少锁的竞争减少锁的竞争能够提高性能和可伸缩性。在并发程序中，对可伸缩性的最主要的威胁就是独占方式的资源锁。有三种方式可以减低锁的竞争程度：减少锁的持有时间降低锁的请求频率使用带有协调机制的独占锁，这些机器允许更好的并发性。//? 11.4.1 缩小锁的范围（快进快出）原理就是Amdah定律，串行的代码总量减少了。 11.4.2 减小锁的粒度这种方式就是降低线程请求锁的频率，通过锁分解来实现。下面的应用明显锁的粒度太粗了。 public class ServerStatusBeforeSplit { @GuardedBy("this") public final Set<String> users; @GuardedBy("this") public final Set<String> queries; public ServerStatusBeforeSplit() { users = new HashSet<String>(); queries = new HashSet<String>(); } public synchronized void addUser(String u) { users.add(u); } public synchronized void addQuery(String q) { queries.add(q); } public synchronized void removeUser(String u) { users.remove(u); } public synchronized void removeQuery(String q) { queries.remove(q); } } 锁分解就是独立的变量独立分配锁，不适用全局锁。优化后如下： public class ServerStatusAfterSplit { @GuardedBy("users") public final Set<String> users; @GuardedBy("queries") public final Set<String> queries; public ServerStatusAfterSplit() { users = new HashSet<String>(); queries = new HashSet<String>(); } public void addUser(String u) { synchronized (users) { users.add(u); } } public void addQuery(String q) { synchronized (queries) { queries.add(q); } } public void removeUser(String u) { synchronized (users) { users.remove(u); } } public void removeQuery(String q) { synchronized (users) { queries.remove(q); } } } 11.4.3 锁分段最典型的例子就是ConcurrentHashMap。 public class StripedMap { // Synchronization policy: buckets[n] guarded by locks[n%N_LOCKS] private static final int N_LOCKS = 16; private final Node[] buckets; private final Object[] locks; private static class Node { Node next; Object key; Object value; } public StripedMap(int numBuckets) { buckets = new Node[numBuckets]; locks = new Object[N_LOCKS]; for (int i = 0; i < N_LOCKS; i++) locks[i] = new Object(); } private final int hash(Object key) { return Math.abs(key.hashCode() % buckets.length); } public Object get(Object key) { int hash = hash(key); synchronized (locks[hash % N_LOCKS]) { for (Node m = buckets[hash]; m != null; m = m.next) if (m.key.equals(key)) return m.value; } return null; } public void clear() { for (int i = 0; i < buckets.length; i++) { synchronized (locks[i % N_LOCKS]) { buckets[i] = null; } } } } 11.4.4 避免热点域hot field 比如HashMap的size方法，ConcurrentHashMap采用了牺牲size的准确性的策略。 11.4.5 一些替代独占锁的方法 ReadWriteLock，AtomicInteger，UNSAFE.compareAndSwap(..) 11.4.6 监测CPU的利用率 vmstat，kill -3 pid ”waiting to lock monitor…“有这句就证明竞争太激烈了。 11.5 示例：比较Map的性能比较了ConcurrentHashMap和synchronized hashmap的性能对比。串行访问Map一个锁 pk 多个线程能并发的访问Map通过分段锁。竞争非常激烈的时候，synchronized hashmap伸缩性非常差，吞吐量不会随着线程数增加而增加，反而降低，因为每个操作消耗的时间大部分都用于上下文切换和调度延迟上了。 11.6 减少上下文切换的开销举个例子，就是APP记录日志，例如写日志到本地或者远程RPC，直接记录会存在I/O阻塞，靠一个轻量级的queue来解耦，使得APP不感知影响，减少阻塞。 http://www.artima.com/insidejvm/ed2/threadsynch.html //TODO 总结了解了性能的提升的几个方面，也了解性能的开销后，应用程序就要根据实际的场景进行取舍和评估。没有一劳永逸的优化方案，不断的进行小范围改进和调整是提高性能的有效手段。当前一些大的架构调整也会导致较大的性能的提升。性能提升考虑的方面：系统平台的资源利用率一个程序对系统平台的资源利用率是指某一个设备繁忙且服务于此程序的时间占所有时间的比率。从物理学的角度讲类似于有用功的比率。简单的说就是：资源利用率=有效繁忙时间/总耗费时间。也就说尽可能的让设备做有用的功，同时榨取其最大值。无用的循环可能会导致CPU 100%的使用率，但不一定是有效的工作。有效性通常难以衡量，通常只能以主观来评估，或者通过被优化的程序的行为来判断是否提高了有效性。延迟延迟描述的是完成任务所耗费的时间。延迟有时候也成为响应时间。如果有多个并行的操作，那么延迟取决于耗费时间最大的任务。多处理多处理是指在单一系统上同时执行多个进程或者多个程序的能力。多处理能力的好处是可以提高吞吐量。多处理可以有效利用多核CPU的资源。多线程多线程描述的是同一个地址空间内同时执行多个线程的过程。这些线程都有不同的执行路径和不同的栈结构。我们说的并发性更多的是指针对线程。并发性同时执行多个程序或者任务称之为并发。单程序内的多任务处理或者多程序间的多任务处理都认为是并发。吞吐量吞吐量衡量系统在单位之间内可以完成的工作总量。对于硬件系统而言，吞吐量是物理介质的上限。在没有达到物理介质之前，提高系统的吞吐量也可以大幅度改进性能。同时吞吐量也是衡量性能的一个指标。瓶颈程序运行过程中性能最差的地方。通常而言，串行的IO、磁盘IO、内存单元分配、网络IO等都可能造成瓶颈。某些使用太频繁的算法也有可能成为瓶颈。可扩展性这里的可扩展性主要是指程序或系统通过增加可使用的资源而增加性能的能力。

2018-02-21

理解 OpenStack Swift （3）：监控和一些影响性能的因素 [Monitoring and Performance]

本系列文章着重学习和研究OpenStack Swift，包括环境搭建、原理、架构、监控和性能等。（1）OpenStack + 三节点Swift 集群+ HAProxy + UCARP 安装和配置（2）原理、架构和性能（3）监控对 Swift 集群的监控是必要的，特别是集群规模很大的时候。 1. 监控目标主要的监控目标包括：硬件故障操作系统故障 Swift集群健康状态 Swift 集群状态 2. Swift 提供的工具 2.1 Swift 自带的各种 Audit 工具 2.1.1 磁盘监控工具swift-drive-audit 该工具分析/var/log/kern.log 文件，根据预定义的 regexp 来探测 kernel 报告的磁盘错误。通常地它会被 cron 周期性地运行。它使用一个配置文件，比如/etc/swift/drive-audit.conf。如果该脚本发现了某个磁盘存在问题，它会自动 unmount 它，而且会在/etc/fstab 中将它注释掉。然后后端 replication 进程就会从其它 replica 中拷贝出一个新的 replica。这是示例配置文件。要使用它，必须首先创建一个配置文件 driver-audit.conf： [drive-audit] device_dir = /srv/node log_facility = LOG_LOCAL0 log_level = INFO minutes = 60 error_limit = 1 log_file_pattern = /var/log/kern* regex_pattern_1 = \berror\b.*\b(dm-[0-9]{1,2}\d?)\b 然后运行该工具：swift-drive-auditdriver-audit.conf，然后上面描述的各种 action 就会有了。 2.1.2 account，container 和 object auditor 功能： swift-account-auditor 会打开 account server 的 sqlite db，运行 SQL 查询，确保 db 是有效的，并报告一个account 是否有 replica 缺失或者错误的对象。 swift-container-auditor 会对 containers 做同样的事情. swift-object-auditor 会打开一个对象服务器上的所有对象，确保它们的元数据是正确的，而且有有合适的大小和 MD5 它们都必须在各自对应的服务的配置文件中的 [account/object/container-auditor] 部分做相应配置，然后它们就会定期运行，并输出日志。 2.2 集群监控状态获取工具swift-dispersion-populate 和 swift-dispersion-report 这两个工具用于获取和报告集群的总体健康状态。它需要访问Swift 集群以及 Ring 文件。它需要一个自己的配置文件，往往把该配置文件放在 proxy server 上的 /etc/swift 目录下。（1）创建配置文件 /etc/swift/dispersion.conf ： [dispersion] auth_url = http://controller:35357/v3 auth_user = service:swift auth_version = 3 auth_key = 1111 swift_dir = /etc/swift concurrency = 25 retries = 5 该配置文件的详细说明可以参见Ubuntu 文档。注意 Kilo 版本的 Swift 环境中需要添加配置项 auth_version。（2）运行swift-dispersion-populate 去获取系统的健康状况，它和 swift-dispersion-report使用同一个配置文件。详细说明可以参见Ubuntu 文档。 root@swift1:/etc/swift# swift-dispersion-populate dispersion.conf Created 10 containers for dispersion reporting, 0s, 0 retries Created 10 objects for dispersion reporting, 0s, 0 retries （3）运行swift-dispersion-report 获取监控报告。详细说明请参加Ubuntu 文档。 root@swift1:/etc/swift# swift-dispersion-report Queried 11 containers for dispersion reporting, 0s, 0 retries 100.00% of container copies found (33 of 33) Sample represents 1.07% of the container partition space Queried 10 objects for dispersion reporting, 0s, 0 retries There were 10 partitions missing 0 copy. 100.00% of object copies found (30 of 30) Sample represents 0.98% of the object partition space 2.3 性能获取工具swift-recon 中间件 2.3.1 它是什么（what） Swift Recon是一个安装在对象服务器的pipeline上的中间件，它有一个必填选项：一个本地缓存目录。它可以获取： How many unmounted (failed) drives there are in the cluster, and on which servers those are located How many async pendings are present Drive usage and balance Load Average (for easy access later on*) Memory Usage (for easy access later on*) Checking ring md5sum’s Logged replication stats Connection stats (tbd) Quarantine Statistics (a new pending addition) 要使用它，需要首先修改 object-server 的配置文件，添加该中间件： [pipeline:main] pipeline = healthcheck recon object-server [filter:recon] use = egg:swift#recon recon_cache_path = /var/cache/swift recon_lock_path = /var/lock 2.3.2 使用命令行工具（How） swift-recon <server_type> [-v] [--suppress] [-a] [-r] [-u] [-d] [-l] [--md5] [--auditor] [--updater] [--expirer] [--sockstat] 参数： -a, --async: Get async stats --auditor: Get auditor stats --updater: Get updater stats --expirer: Get expirer stats -r, --replication: Get replication stats -u, --unmounted: Check cluster for unmounted devices -d, --diskusage: Get disk usage stats -l, --loadstats: Get cluster load average stats -q, --quarantined: Get cluster quarantine stats --md5 Get md5sum of servers ring and compare to local cop --all Perform all checks. Equivalent to -arudlq --md5 -z ZONE, --zone=ZONE: Only query servers in specified zone --swiftdir=PATH Default = /etc/swift （1）获取全部zone 上 updater，auditor 和 expier 的状态 root@swift1:/etc/swift# swift-recon --auditor --updater --expirer =============================================================================== --> Starting reconnaissance on 3 hosts =============================================================================== [2015-11-14 16:52:00] Checking auditor stats [ALL_audit_time_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [ALL_quarantined_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [ALL_errors_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [ALL_passes_last_path] low: 1, high: 1, avg: 1.0, total: 3, Failed: 0.0%, no_result: 0, reported: 3 [ALL_bytes_processed_last_path] low: 5, high: 5, avg: 5.0, total: 15, Failed: 0.0%, no_result: 0, reported: 3 [ZBF_audit_time_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [ZBF_quarantined_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [ZBF_errors_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [ZBF_bytes_processed_last_path] low: 0, high: 0, avg: 0.0, total: 0, Failed: 0.0%, no_result: 0, reported: 3 =============================================================================== [2015-11-14 16:52:00] Checking updater times [updater_last_sweep] low: 0, high: 0, avg: 0.1, total: 0, Failed: 0.0%, no_result: 0, reported: 3 =============================================================================== [2015-11-14 16:52:00] Checking on expirers [object_expiration_pass] - No hosts returned valid data. [expired_last_pass] - No hosts returned valid data. =============================================================================== （2）磁盘使用情况 root@swift1:/etc/swift# swift-recon -d =============================================================================== --> Starting reconnaissance on 3 hosts =============================================================================== [2015-11-14 16:53:38] Checking disk usage now Distribution Graph: 2% 2 ********************************************** 3% 3 ********************************************************************* 4% 1 *********************** Disk usage: space used: 5343854592 of 160982630400 Disk usage: space free: 155638775808 of 160982630400 Disk usage: lowest: 2.59%, highest: 4.56%, avg: 3.31952247191% （3）系统负载 root@swift1:/etc/swift# swift-recon -l =============================================================================== --> Starting reconnaissance on 3 hosts =============================================================================== [2015-11-14 16:54:32] Checking load averages [5m_load_avg] low: 0, high: 0, avg: 0.1, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [15m_load_avg] low: 0, high: 0, avg: 0.1, total: 0, Failed: 0.0%, no_result: 0, reported: 3 [1m_load_avg] low: 0, high: 0, avg: 0.1, total: 0, Failed: 0.0%, no_result: 0, reported: 3 （4）检查所有节点上的 ring 文件和 swift.conf 是不是完全一致 root@swift1:/etc/swift# swift-recon --md5 =============================================================================== --> Starting reconnaissance on 3 hosts =============================================================================== [2015-11-14 17:08:38] Checking ring md5sums 3/3 hosts matched, 0 error[s] while checking hosts. =============================================================================== [2015-11-14 17:08:38] Checking swift.conf md5sum 3/3 hosts matched, 0 error[s] while checking hosts 2.3.2 通过 REST API 使用 URL 及功能列表： 3. 其它监控工具 Swift 自身带的监控工具能提供比较丰富的功能，但是使用起来还不是很方便，因此，业界已经出现了很多商业的或者开源的监控工具。这些监控工具，要么向 swift-recon 一样实现了一个新的中间件，要么调用 Swift 自身的工具提供的接口。以下（1 - 4 部分）文字引用自OpenStack Object Storage Monitoring一文：（1）Swift-Informant Florian Hines 开发的 Swift-Informant 中间件可以获得 OS 客户请求的实时结果。它位于proxy server的 pipeline，在每一个请求到达Proxy server之后，它发送3类统计数据到StatsD server. 一个类似obj.GET.200 or cont.PUT.404的增量计数器。请求处理的时间长度传输数据数量这有利于了解客户正体验的服务品质，也可以了解各种服务类型，命令以及响应码的不同排列的数量。Swift-Informant也要求no change to core Swift code因为它是用中间件实现的。然而，也因为如此，它不能让人看到代理服务器后面的工作情景。如果一个存储节点的响应降低，你也可能看到你的请求变差－要么是高延迟，要么返回错误状态码。你不会知道具体是为什么，或者请求是要去哪里。或许你所考虚的container服务器是在一个好的节点的，而对象服务器是在另一个性能差的节点。因此我们需要深入视觉到proxy server的后面，集群的操作里去。（2）Statsdlog Florian 的 statsdlog 工程增加了 StatsD 基于日志事件的计数器。正如Swift-Informant，它也是非侵入式的。但是statsdlog可以从Swift后台进程中追踪事件，而不仅仅是代理服务器。后台进程监听syslog信息的UDP流，当一条日志匹配于一个正则表达式时，StatsD计数器递增。Metric名字映射到JSON文件中的正则pattern。JSON文件允许灵活配置以能从日志流中抽取出想要的metrics。（3）Swift StatsD Logging StatsD 使用程序代码来作深入分析。Metrics被有针对性的代码实时发送。发送一个metric的开销相当低：一个sendto UDP包。如果你认为这样的开销还算高的话，StatsD client library可以只发送样本的随机比率部分，flushing metrics upstream时StatsD将估算实际数据。要避免基于中间件的监控与事后日志处理所带来的弊端，我们把StatsD metrics发送过种整合到Swift本身。我们当前所提交的更改报告了遍布15个swift后台进程的124个metrics以及tempauth中间件。metrics细节可参考https://review.openstack.org/#patch,sidebyside,6058,2,doc/source/admin_guide.rst （4）总结我们认为 Swift 集群动作最好的监控方法是综合了一个通用服务器监控系统，一个Swift特定统计指标收集（polling Swift-specific gauge metrics）机制，一个Swift内部counter与timing metrics深度StatsD日志手段的结合体。对于polling Swift-specific gauge metrics，最好使用一个通用的收集插件。这个插件即可以从swift-recon读数据，也可以自己直接收集信息。在 SwiftStack，我们使用 collectd 加上一些服务器监控用 python 插件代码。我们也在collectd中嵌入StatsD服务器，这样每个节点都有一个进程将stats数据“倒”给Graphite"(http://graphite.wikidot.com/)集群。有了这个装置，我们拥有前述所有问题的全覆盖解决方案：general purpose monitoring, Swift-specific gauge monitoring, and real-time counter and timing data directly from Swift。除了图形化，你也可以实现异常检测，触发警告，维护一个实时的实体健康状态视图，避免各种突发问题。（5）SwiftStack 监控工具的部分截图：（6）另外一个监控环境示例（7）Benchmarking 工具 Intel 开源了对象存储的 Benchmarking 工具 COSBench，https://github.com/intel-cloud/cosbench 4. 一些影响性能的因素注：以下内容引用自 "Leveraging open source tools to gain insight into OpenStack Swift“ ，byMichael Factor,Dmitry Sotnikov, dmitrys@il.ibm.com。他们使用的测试环境： 4.1 Container 数量和 Swift 版本（PUT 操作）版本和 container 数目带来的性能差异还是非常大的。建议使用 Swift 2.2 版本以上，以及多个 container。 4.2 客户端 worker 数目可见客户端 worker 数目不是越多性能就会线性增加。 4.3 Container 中的对象数目 4.4 前端和后端网络带宽说明后端网络的带宽压力是前端的至少3倍。 4.5 存储节点的磁盘I/O 和前端网络 I/O 的关系（12倍） 4.6 对象大小这说明 Swift 不合适处理大量的小文件。 4.7 IOPS 性能不是随着存储节点数目线性扩展的也就是说这个环境中，存储节点数目为7的话，它们就不是 IOPS 性能瓶颈了。参考文档： http://www.cnblogs.com/Clisa/p/3461701.htmlhttps://swiftstack.com/blog/2012/04/11/swift-monitoring-with-statsd/https://platform.swiftstack.com/docs/admin/monitoring/cluster-monitoring.html http://blog.chmouel.com/2012/02/01/audit-a-swift-cluster/

2017-11-08

secret-performance-desktop v2.1.2 已经发布，基于 JavaFx 的桌面个性化工具

secret-performance-desktop v2.1.2 已经发布，这是一个基于 javafx 的桌面个性化工具。

2021-02-18

在 Node.js 中精准统计代码执行耗时：process.hrtime 与 performance.now 怎么选

## performance.now 更接近浏览器习惯 Node 8.5 之后提供了 `perf_hooks` 模块，API 和浏览器里的 `performance.now()` 基本一致： ```js

2026-09-25

Node.js技术原理分析系列——Node.js的perf_hooks模块作用和用法

doSomeLongRunningProcess(() => { performance.measure('A to Now', 'A'); performance.mark('B'); performance.measure

2025-02-24

React Native Skills 实用指南

- 处理图像和媒体资源 - 配置原生模块或字体 - 构建包含原生依赖的 monorepo 项目 ## 规则类别（按优先级）优先级类别影响前缀 1 列表性能 CRITICAL list-performance

2026-09-12

Oracle 推出 JDK 8 的直接替代品

为了向传统的 Java 8 服务器工作负载提供 Java 17 级别的性能，Oracle宣布推出 Java SE Subscription Enterprise Performance Pack (Enterprise

2022-10-20

Apify Content Analytics 实用指南

Growth metrics Comment engagement apify/instagram-comment-scraper Comment analysis Hashtag performance

2026-08-31

GreatSQL内存消耗异常排查攻略：从系统到应用层面的深入分析

利用 Performance Schema 排查内存消耗来源从 5.6.6 版本开始，Performance Schema 默认启用，是一个内置的性能诊断工具，用于实时监控和分析 GreatSQL 服务器的运行状态

2024-11-29

MySQL主从架构由5.5版本升级到5.6方案

etc/init.d/mysqld-5.6 start 然后观察错误文件，会看到如下报错： 2015-08-04 13:16:31 18815 [ERROR] Native table 'performance_schema

2017-11-02

聊聊 PerformanceObserver

2 历史说起 PerformanceObserver，我们首先要了解下 Performance Timeline。

2023-04-06

elasticsearch index性能优化建议

转自： https://qbox.io/blog/maximize-guide-elasticsearch-indexing-performance-part-3 https://qbox.io/blog

2018-01-14

测试 JavaScript 函数的性能

一般来说，完成这个任务的最佳方式是使用内置的performance.now()函数，来衡量函数运行前和运行后的时间。

2018-06-12

Vulkan 1.1.128 发布，带有性能查询扩展

对于Vulkan 1.1.128来说，新扩展名是VK_KHR_performance_query。此KHR批准的扩展是Vulkan中的第一个跨供应商扩展，用于查询硬件上的任何性能计数器。

2019-11-19

大数据技术的对决——Spark对Impala对Hive对Presto

Spark 2.0 improved its large query performance by an average of 2.4X over Spark 1.6 (so upgrade!).

2017-07-31

如何限制用户修改long_query_time

解决方法在 performance_schema 中有表 variables_by_thread 存储了每个活动会话的会话级系统变量。

2024-10-30

Python 重要性水平与错报汇总评价

javascript bench_name = "profit_before_tax" benchmark = 5000000 pct = 0.05 overall = benchmark * pct performance

2026-08-29

如何实现比 setTimeout 快 80 倍的定时器？

用如下代码做个测试： let a = performance.now(); setTimeout(() => { let b = performance.now(); console.log(b

2021-05-17

资源下载

更多资源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能，例如代码缩略图，Python的插件，代码段等。还可自定义键绑定，菜单和工具栏。Sublime Text 的主要功能包括：拼写检查，书签，完整的 Python API ， Goto 功能，即时项目切换，多选择，多窗口等等。Sublime Text 是一个跨平台的编辑器，同时支持Windows、Linux、Mac OS X等操作系统。