[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-18。"],[],[],null,["# Profiling concepts\n==================\n\nProfiling is a form of dynamic code analysis. You capture characteristics of\nthe application *as it runs*, and then you use this information to identify\nhow to make your application faster and more efficient.\n\nHistorically, profiling was performed only during application development. This\napproach relied on the ability to develop load tests and benchmarks that\ncould accurately predict a production environment.\n\n*Continuous profiling* refers to profiling the application while it executes\nin a production environment. This approach alleviates the need to develop\naccurate predictive load tests and benchmarks for the production environment.\nResearch on continuous profiling has shown it is accurate and\ncost effective^\\*^.\n\nCloud Profiler is a continuous profiling tool that is designed for\napplications running on Google Cloud:\n\n- It's a statistical, or sampling, profiler that has low\n overhead and is suitable for production environments.\n\n- It supports common languages and collects multiple profile types.\n See [Types of profiling available](#types_of_profiling_available)\n for an overview.\n\nConfiguring a Google Cloud application to generate profile data\nis a simple, one time process: link or run your service with a profiling\nagent included. After your application is deployed, the\n*profiling agent* runs periodically to gather performance data and then\nsends that data to your Google Cloud project. For details about this process,\nsee [Profile collection](#collection).\n\nAfter you have collected profile data for your application, you can analyze\nthe data by using the Profiler interface.\nAnalyzing profile data is typically an iterative process that relies on your\nknowledge of the application design and its programming language.\n\n^\\*^See the following [Google-Wide Profiling: A Continuous Profiling Infrastructure for Data Centers](https://research.google/pubs/pub36575/) and [Continuous Profiling: Where Have All the Cycles Gone?](https://dl.acm.org/doi/10.1145/265924.265925).\n\nTypes of profiling available\n----------------------------\n\nThe following table summarizes the supported profile types:\n\nThe remainder of this section provides more detail about each of these\nprofile types.\n\n### Time measurements\n\n- **CPU time** is the time the CPU spends executing a block of code.\n\n The CPU time for a function tells you how long the CPU was busy executing\n instructions. It doesn't include the time the CPU\n was waiting or processing instructions for something else.\n- **Wall-clock time** (also called *wall time*) is the time it takes\n to run a block of code.\n\n The wall-clock time for a function measures the time elapsed between\n entering and exiting a function. Wall-clock time includes all wait time,\n including that for locks and thread synchronization.\n The wall time for a block of code can never be less than the CPU time.\n | **Note:** When the number of samples is low, the wall time can appear to be less than the CPU time in a sampling profile such as Cloud Profiler.\n\nIf the wall-clock time is longer than the CPU time, then that\nindicates the code spends time waiting. When the difference is\nsubstantial, your application might have a resource bottleneck.\n\nIf the CPU time is similar to the wall time, then that indicates the\ncode is CPU intensive; almost all the time it takes to run is spent by the\nCPU. Long-running CPU-intensive blocks of code might be candidates for\noptimization.\n\n### Heap (memory) usage\n\n- **Heap usage** (also called *heap*) is the amount of memory allocated\n in the program's heap at the instant the profile is collected. Unlike\n other profile types where data is collected over an interval, this\n profile type collects the heap usage at a single point in time.\n\n- **Heap allocation** (also called *allocated heap*) is the total amount\n of memory that was allocated in the program's heap during the interval in\n which the profile was collected. This value includes any memory that was\n allocated and has been freed and is no longer in use. As an example,\n consider a job that repeats the following sequence: allocates 1 MiB,\n waits 500 msec, frees 1 MiB, waits 500 msec. In the 10 seconds in which\n the allocated heap profile is collected, there are 10 allocations and\n 10 frees. This profile would show 10 MiB allocated heap, as the frees aren't\n considered. The average rate\n of allocation is 10 MiB/10 seconds or 1 MiB per second.\n\nProfiling heap usage helps you find potential inefficiencies and memory\nleaks in your programs. Profiling heap allocations helps you know which\nallocations are causing the most work for the garbage collector.\n\n### Threading information\n\nApplications that create threads can suffer from blocked threads and from\nthread leaks:\n\n- Blocked threads are threads that are created but are waiting for a lock. These threads are not currently running, and they might never run. However, a blocked thread might eventually run.\n- Thread leaks occur when the number of created threads keeps increasing.\n\nBlocked threads are one cause of leaked threads.\n\nAt the frame level, the **Thread** profile displays the average number of\nthreads that include that frame. This profile type collects thread usage at a\nsingle point in time.\n\n### Contention\n\nIn a multi-threaded program, the time spent waiting to serialize access\nto a shared resource can be significant. Understanding contention behavior\ncan guide the design of the code and provide information for performance\ntuning.\n\nProfile collection\n------------------\n\nThe role of the profiler agent is to capture profile data from your application\nand to transmit this data to the Profiler backend using the\nProfiler API. Each profile is for a single instance of an\napplication and it includes four fields that uniquely identify its deployment:\n\n- Google Cloud project\n- Application name\n- Application zone\n- Application version\n\nWhen an agent is ready to capture a profile, it issues a Profiler\nAPI command to the Profiler backend. The backend receives this\nrequest and, in the simplest scenario, immediately replies to the agent. The\nreply specifies the type of profile to capture. In response, the agent captures\nthe profile and transmits it to the backend. Lastly, the Profiler\nbackend associates the profile with your Google Cloud project. You can\nthen view and analyze it by using the Profiler interface.\n\nThe actual handshake sequence is more complex than described in the previous\nparagraph. For example, when the Profiler receives a request\nfrom an agent, the backend checks its\ndatabase to determine if it has received previous requests from the agent.\nIf not, the backend adds the agent information to its database. A new deployment\nis created if the agent deployment fields don't match the settings of any other\nrecorded agent.\n\nEach minute, on average, and for each deployment and each profile type, the\nbackend selects an agent and instructs it to capture a profile.\nFor example, if the agents for a deployment support Heap and Wall time\nprofiling, on average, two profiles are captured each minute:\n\n- For all profile types except heap usage and threads, a\n single profile represents data collected for 10 seconds.\n\n- Heap usage and thread profiles are collected\n instantaneously.\n\nAfter the agent notifies the Profiler\nbackend that it's ready to capture data, the agent idles until the backend\nreplies with the type of profile to capture.\nIf you have 10 instances of an application running in the same deployment, then\nyou create 10 profiling agents. However, most of the time these agents are idle.\nOver a 10-minute period, you can expect 10 profiles;\neach agent receives one reply for each profile type, on average.\nThere is some randomization involved, so the actual number might vary.\n\nThe Profiler backend uses Profiler API quotas and\nthe profile deployment fields to limit the profiles ingested.\nFor information on viewing and managing your Profiler quotas,\nsee [Quotas and limits](/profiler/quotas).\n\nAnalyzing data\n--------------\n\nAfter Profiler has collected data, you can view and analyze\nthis data using the Profiler interface.\n\nIn the Google Cloud console, go to the **Profiler** page:\n\n[Go to **Profiler**](https://console.cloud.google.com/profiler)\n\n\u003cbr /\u003e\n\nYou can also find this page by using the search bar."]]
