WO2024049570A1 - Collecte et représentation de piles d'appels de programme - Google Patents

Collecte et représentation de piles d'appels de programme Download PDF

Info

Publication number
WO2024049570A1
WO2024049570A1 PCT/US2023/028306 US2023028306W WO2024049570A1 WO 2024049570 A1 WO2024049570 A1 WO 2024049570A1 US 2023028306 W US2023028306 W US 2023028306W WO 2024049570 A1 WO2024049570 A1 WO 2024049570A1
Authority
WO
WIPO (PCT)
Prior art keywords
stack
graph
flow
stacks
sequence
Prior art date
Application number
PCT/US2023/028306
Other languages
English (en)
Inventor
Beau Allen Belgrave
Original Assignee
Microsoft Technology Licensing, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US18/087,652 external-priority patent/US20240069879A1/en
Application filed by Microsoft Technology Licensing, Llc filed Critical Microsoft Technology Licensing, Llc
Publication of WO2024049570A1 publication Critical patent/WO2024049570A1/fr

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3003Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3037Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a memory, e.g. virtual memory, cache
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/34Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466Performance evaluation by tracing or monitoring
    • G06F11/3471Address tracing
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/32Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/323Visualisation of programs or trace data

Definitions

  • a call stack is a data structure that stores information about the flows of a computer program being executed. More specifically, a flow captures a call from one programming element to another programming element.
  • the flows that can be added to a call stack include dedicated locations in memory (e.g., memory blocks) useable by a compiler and/or a processing unit (e.g., a central processing unit (CPU)).
  • the dedicated locations are typically represented by a set of addresses (e.g., addresses “0000”-“9999”).
  • a call stack includes a plurality of flows in a defined sequence (e.g., flow A includes a call to flow B, which includes a call to flow C, and so forth).
  • a flow in the call stack is represented by an address (e.g., flow A is represented by flow address “4096”). While a call stack can include any number of flows, a relatively small call stack generally includes eight to twelve flows while a relatively large call stack generally includes thirty to one hundred flows. It is worth noting that a call stack may alternatively be referred to as an execution stack, a program stack, a control stack, a run-time stack, or a machine stack, and is often referred to as simply the stack.
  • a large number of stacks may need to be collected and stored.
  • a cloud provider with multiple datacenters collects and analyze upwards of trillions of stacks every day. This collection and analysis can result in a large carbon footprint for the organization due to the energy used to operate resources to collect, to store, and/or to analyze the large number of stacks.
  • the disclosed techniques implement an improved format for transmitting call stacks (referred to herein as stacks) from machines to a stack analysis service. Moreover, the techniques implement an improved way for the stack analysis service to represent the large number of stacks.
  • the improved format enables the collection of a large number of stacks (e.g., millions or even trillions of stacks) to be more efficient.
  • the improved representation of a large number of stacks enables the analysis to be more efficient. Consequently, the techniques described herein reduce the carbon footprint for an organization that operates a group of machines because less network, storage, and/or processing resources are needed to collect and analyze a large number of stacks.
  • a stack is a data structure that stores information about the flows of a computer program being executed. More specifically, a flow captures a call from one programming element (e.g., a subroutine, a function, a statement) to another programming element. Consequently, a stack includes a sequence of flows (may alternatively be referred to herein as a flow sequence) .
  • flows that can be added to a stack reside in dedicated locations in memory (e.g., memory blocks) useable by a compiler and/or a processing unit (e.g., a central processing unit (CPU)).
  • the dedicated locations are typically represented by a set of addresses (e.g., addresses “0000”-“9999”).
  • a flow in a stack is typically represented by an address (e.g., flow A is represented by flow address “4096”).
  • the format for transmitting a stack from a machine to a stack analysis service employs an actual address to represent the first flow in the sequence of flows included in the stack. This actual address serves as a baseline address for the stack. However, the format does not employ actual addresses to represent the flows in the sequence of flows after the first flow. Rather, the format employs an address offset to represent each flow in the sequence of flows after the first flow.
  • the address offset is a difference between an address of a current flow and an address of a previous flow that calls on the current flow. For instance, an address offset for flow B is the difference between the actual address for flow B and the actual address for flow A, an address offset for flow C is the difference between the actual address for flow C and the actual address for flow B, and so forth.
  • address offsets enables storage space to be conserved and/or enables compression ratios related to the transmission of stacks to be increased because the values for the address offsets are typically smaller compared to the values for the actual addresses.
  • the values for the address offsets are typically smaller compared to the values for the actual addresses because operating systems and/or compilers strive for high storage locality with regard to related programming elements. That is, programming elements that often call on one another are typically stored, e.g., by an operating system and/or a compiler, close to one another in memory (e.g., the addresses are close).
  • the techniques further improve the efficiency with which stacks are transmitted by variable bit encoding the address offsets representing the flows in the stack.
  • variable bit encoding rather than conventional compression techniques (e.g., DEFLATE data compression, ZIP data compression), which require scanning previously seen data and finding duplicated parts of the data. Consequently, variable bit encoding the address offsets, rather than using entire addresses associated with machines, operating systems, and/or CPUs configured for sixty-four bit operation, allows for a lower processing cost to be realized, which is ideal in environments (e.g., datacenter operators, cloud providers) that are sensitive to power consumption and carbon footprints.
  • variables bit encoding the address offsets rather than using entire addresses associated with machines, operating systems, and/or CPUs configured for sixty-four bit operation, allows for a lower processing cost to be realized, which is ideal in environments (e.g., datacenter operators, cloud providers) that are sensitive to power consumption and carbon footprints.
  • the stack analysis service collects the stacks and generates flow identifications for each of the flows in a stack.
  • the stack analysis service is configured to recalculate an address for each flow in the stack using the baseline address that represents the first flow and the address offsets that represent the flows after the first flow.
  • the addresses used for specific flows are consistent, or the same, across a fleet of machines, which enables the improved representation of a large number of stacks, as further described herein. For instance, if flow A is stored in address “4032” on one machine in the fleet, then flow A is stored in address “4032” across the machines in the fleet.
  • the stack analysis service is configured to generate a graph for a group of stacks (e.g., the stacks in a stack file).
  • the stack analysis service is configured to receive a stack file from each machine in a fleet of machines.
  • the stack analysis service is configured to receive a single stack file from a predefined group of machines (e.g., two machines, three machines, ten machines).
  • the graph includes a plurality of entries where each entry represents a unique sequence of flows.
  • the stack analysis service sequentially reads the stacks in a stack file (e.g., one by one). For the first stack sequentially read and/or for the first sequence of flows encountered, the stack analysis service adds an entry to the graph. Again, the entry represents the sequence of flows in the first stack that is sequentially read from the stack file. For each stack that is sequentially read from the stack file after the first stack, the stack analysis service uses the flow identifications to determine whether the sequence of flows included in the stack currently being sequentially read from the stack file (i.e., the “current” or “remaining” stack) matches a sequence of flows in a previous stack that has already been sequentially read from the stack file.
  • the stack analysis service increments a weight value for the entry.
  • the weight value represents a number of times the sequence of flows occurs in different stacks. If the sequence of flows in the current stack does not match the sequence of flows in the previous stack, meaning the graph does not yet include an entry for the sequence of flows in the current stack, then the stack analysis service adds a new entry to the graph.
  • the stack analysis service can additionally be configured to use a pointer from a flow identification (e.g., a flow node) in one entry of the graph to the same flow identification in a different entry in the graph. For example, in response to determining that the sequence of flows in the current stack does not match the sequence of flows in the previous stack, the stack analysis service looks in the existing entries of the graph for flow identifications that match flow identifications in the new entry added to the graph. In the event of a match, the stack analysis service adds a pointer from the flow in the new entry to the matching flow in an existing entry. By representing the stacks of a stack file in a graph using a number of times each unique sequence of flows is encountered in the stacks, the deduplication of data is enabled.
  • a flow identification e.g., a flow node
  • the entries in the graph are ordered according to decreasing weight values. This ensures that entries that are seen more often in the stacks of a stack file (e.g., entries with the higher hit counts), and which are typically more important or significant from an analysis perspective, show up first when the graph is being read from disk. For instance, even when a small percentage of the data in the graph has been read, a clear picture of the performance of the fleet is apparent.
  • a weight value threshold can be used to trim the graph. That is, the stack analysis service is configured to determine that a weight value for an entry in the graph fails to satisfy a weight value threshold (e.g., the weight value is below the weight value threshold). Based on this determination, the stack analysis service removes the entry from the graph. This can further improve the efficiency with regard to transmitting, storing, and/or processing the stack data in the graph because rarely encountered entries can be removed.
  • the growth in the stack data e.g., the increase in stacks
  • the amount of stack data to process and store can grow endlessly, at a large resource cost.
  • graphs e.g., trimmed graphs
  • entry weights can be efficiently merged with one another. For example, weight values for matching entries in two graphs can be combined and represented in a merged graph.
  • This merging can recursively occur as the collected stack data increases, and as a result of this recursive merging, one graph can represent a large number of stack files and/or stacks.
  • the trimming of graphs, and/or the merging of graphs the analysis of stacks can be scaled. For example, due to the space reductions and the removal of constraints, a graph for stacks collected from a fleet of customer machines can be placed in a customer allocated storage account.
  • the graph can also include playback data.
  • the playback data includes a timestamp associated with execution of a flow, as well as properties associated with the execution of the flow.
  • Example properties include a process identification (PID) and/or a thread identification (TID).
  • PID process identification
  • TID thread identification
  • FIG. 1 illustrates an example environment in which machines implement an improved format for transmitting stacks to a stack analysis service and/or in which the stack analysis service can more efficiently represent a large number of stacks in a graph.
  • FIG. 2 illustrates an example diagram that captures the technical benefits of using an address offset format and/or variable bit encoding when transmitting stacks from a machine to the stack analysis service.
  • FIG. 3 A illustrates an example diagram that captures the technical benefits of using the graph to represent the stacks with entries and/or entry weight values.
  • FIG. 3B illustrates an example diagram that captures the technical benefits of using the graph to represent the stacks with entries, entry weight values, and/or pointers.
  • FIG. 4 illustrates an example diagram that trims the graph representing the stacks with entries, entry weight values, and/or pointers.
  • FIG. 5 A illustrates an example diagram directed to merging two trimmed graphs.
  • FIG. 5B illustrates an example diagram that shows the merged graph, after the merging of the two trimmed graphs of FIG. 5 A.
  • FIG. 6 illustrates an example diagram in which playback data is associated with each node in the graph.
  • FIG. 7 is an example flow diagram showing aspects of a method implemented by a machine to represent a stack using a format that includes address offsets.
  • FIG. 8 is an example flow diagram showing aspects of a method implemented by a stack analysis service to generate the graph representing stacks in a stack file.
  • FIG. 9 is a computer architecture diagram showing an illustrative computer hardware and software architecture for a computing system capable of implementing aspects of the techniques and technologies presented herein.
  • the techniques described herein implement an improved format for transmitting call stacks (referred to herein as stacks) from machines to a stack analysis service. Moreover, the techniques implement an improved way for the stack analysis service to represent the large number of stacks.
  • the improved format enables the collection of a large number of stacks (e.g., millions or even trillions of stacks) to be more efficient.
  • the improved representation of a large number of stacks enables the analysis to be more efficient. Consequently, the techniques described herein reduce the carbon footprint for an organization that operates a group of machines because less network, storage, and/or processing resources are needed to collect and analyze a large number of stacks.
  • FIGS. 1-9 Various examples, scenarios, and aspects that enable the techniques described herein are described below with respect to FIGS. 1-9.
  • FIG. 1 illustrates an example environment 100 in which machines 102(l-N) implement an improved format for transmitting stacks to a stack analysis service 104 and/or in which the stack analysis service 104 can more efficiently represent a large number of stacks in a graph.
  • the machines 102(l-N) can include servers or other types of machines (e.g., laptop devices, tablet devices, smartphone devices, Internet of Things (loT) devices) that comprise a fleet 106 configured and/or operated by an organization (e.g., an operator of public cloud datacenters).
  • the stack analysis service 104 can be executed, for example, on one or more servers.
  • Each machine 102(l-N) includes at least one central processing unit (CPU) 108(l-N).
  • CPU central processing unit
  • Each CPU 108(l-N) is configured to generate corresponding stacks 110(l-N) over a period of time (e.g., seconds, minutes, hours).
  • a stack is a data structure that stores information about the flows of a computer program being executed by one of the CPUs 108(l-N). More specifically, a flow captures a call from one programming element (e.g., a subroutine, a function, a statement) to another programming element in the computer program.
  • the flows added to the stacks 110(l-N) by the CPUs 108(l-N) include dedicated locations in memory (e.g., memory blocks). The dedicated locations are typically represented by a set of addresses (e.g., addresses “0000”-“9999”). Consequently, each of the stacks 110(l-N) includes a sequence of flows and a flow in the stack is represented by an address.
  • the stack analysis service 104 can collect and analyze the stacks 110(l-N) to identify the most frequently used programming elements, to determine systemic costs with regard to modifying programming elements, to identify which programming elements use most of the processing time, to implement stack traces for debugging purposes, etc.
  • the stack analysis service 104 includes a stack file collection module 112, a graph generation module 114, a graph trimming module 116, a graph merging module 118, and a stack analysis module 120, each of which is discussed further herein.
  • the functionality described herein in association with the illustrated modules may be performed by a fewer number of modules or a larger number of modules.
  • the stack file collection module 112 uses an address offset format 122 to represent the flows in a stack.
  • the stack file collection module 112 pushes the address offset format 122 to the machines 102(l-N) in the fleet 106.
  • the machines 102(l-N) are configured to locally generate stack files 124(1-N) that include the stacks 110(l-N) recently configured by the CPUs 108(l-N).
  • a stack file includes at least one stack.
  • the stack file collection module 112 can be configured to collect the stack files 124(1-N) in accordance with a schedule 126 (e.g., every hour, every two hours, once a day) established based on various factors.
  • a schedule 126 e.g., every hour, every two hours, once a day
  • the stack file collection module 112 can be configured to collect the stack files 124(1-N) based on an occurrence of an event 128 (e.g., a system failure, a cyberattack).
  • an event 128 e.g., a system failure, a cyberattack
  • the machines 102(l-N) Prior to transmitting the stack files 124(1-N) to the stack analysis service 104, based on the schedule 126 and/or based on an occurrence of an event 128, the machines 102(l-N) are configured to generate and/or format the stacks 110(l-N) in the address offset format 122.
  • the address offset format 122 employs an actual address to represent the first flow in the sequence of the stack. This actual address can be referred to as a baseline address for the stack.
  • the address offset format 122 does not employ actual addresses to represent the flows in the sequence of the stack after the first flow. Rather, the address offset format 122 employs an address offset to represent each flow in the sequence after the first flow.
  • the address offset is a difference between an address of a current flow and an address of a previous flow that calls on the current flow.
  • the techniques further improve the efficiency with which stacks are transmitted by variable bit encoding the address offsets representing the flows in the stack. That is, the processing power used to prepare a stack for transmission is reduced by using variable bit encoding rather than conventional compression techniques (e.g., DEFLATE data compression, ZIP data compression), which require scanning previously seen data and finding duplicated parts of the data. Consequently, variable bit encoding the address offsets, rather than using entire addresses associated with machines, operating systems, and/or CPUs configured for sixty-four bit operation, allows for a lower processing cost to be realized, which is ideal in environments (e.g., datacenter operators, cloud providers) that are sensitive to power consumption and carbon footprints.
  • An example of the technical improvements provided by the address offset format 122 and/or the variable bit encoding is provided in FIG. 2.
  • the stack file collection module 112 passes the stack files 124(1-N) to the graph generation module 114.
  • the graph generation module 114 is configured to generate flow identifications 130 for each of the flows in a stack, as further described herein with respect to FIG. 2. Furthermore, the graph generation module 114 is configured to generate a graph that represents the stack in a manner that reduces the use of storage and processing resources.
  • the graph generation module 114 generates a graph 132 with entries, weights, and/or pointers for each stack file 124(1-N), as further described herein with respect to FIG. 3.
  • a graph includes a plurality of entries where each entry represents a unique sequence of flows.
  • each entry in the graph includes a weight value that tracks the number of times the unique sequence of flows occurs in the stacks of a single stack file or multiple stack files. While FIG. 1 illustrates that a stack file 124(1-N) is collected from each machine 102(l-N) in the fleet 106, a stack file can be collected from a predefined group of machines (e.g., two machines, three machines, ten machines).
  • the deduplication of data is enabled. Consequently, the graph allows for more efficient storage and/or more efficient transmission from one location (e.g., one server) to another location (e.g., another server).
  • a weight value threshold 134 can be used to trim the graph 132. That is, the graph trimming module 116 is configured to determine that a weight value for an entry in the graph 132 fails to satisfy the weight value threshold 134 (e.g., the weight value is below the weight value threshold). Based on this determination, the graph trimming module 116 removes the entry 136 from the graph, as described herein with respect to FIG. 4. This trimming can further improve the efficiency with regard to transmitting, storing, and/or processing the stack data in the graph because rarely encountered entries can be removed. Generally, the growth in the stack data (e.g., the increase in stacks) to be represented is driven by rarely occurring flow sequences (e.g., a flow sequence that occurs only one time). Without trimming these rarely occurring flow sequences, the amount of stack data to process and store can grow endlessly, at a large resource cost.
  • the graph trimming module 116 is configured to determine that a weight value for an entry in the graph 132 fails to satisfy the weight value threshold 134 (e.g., the weight value
  • graphs can be efficiently merged with one another.
  • the graph merging module 118 can take the weight values for a matching entry in the two different graphs and add them together to calculate a combined weight value for a merged graph 138. This merging can recursively occur as the collected stack data increases (e.g., more and more stack files 124(1-N) are received).
  • the graph merging module 118 can pass a single graph 140, that represents a large number of stacks 110(1- N) and/or stack files 124(1-N) to the stack analysis module 120.
  • the graph merging module 118 can efficiently pass (e.g., transmit, communicate) the single graph to a different consumer (e.g., a user device, a client, a tenant, a customer).
  • a different consumer e.g., a user device, a client, a tenant, a customer.
  • this mitigates the need to maintain a dedicated database for storing, processing, and managing the stacks l lO(l-N) and/or stack files 124(1-N).
  • the analysis of stacks can be scaled.
  • FIG. 2 illustrates an example diagram that captures the technical benefits of using an address offset format and/or variable bit encoding when transmitting stacks from a machine to a stack analysis service.
  • the conventional approach of using an actual address format 202 is used to transmit a stack 204.
  • the stack 204 includes Flow A represented by address “4096” 206, Flow B represented by address “4000” 208, Flow C represented by address “3800” 210, Flow D represented by address “4024” 212, and Flow E represented by address “1024” 214.
  • the actual addresses each use eight bytes of space when the machines 102(l-N) are sixty-four bit machines, as shown via elements 216, 218, 220, 222, and 224. Consequently, transmission of the stack 204 consumes forty bytes 226 when using the actual address format 202.
  • FIG. 2 illustrates the technical benefits achieved by using an address offset format 122 to transmit the same stack 204.
  • Flow A in the stack 204 is still represented by the baseline - address “4096” 206.
  • Flow B is represented by the difference between address “4000” of the current flow and address “4096” of the previous flow, or “-96” 228.
  • Flow C is represented by the difference between address “3800” of the current flow and address “4000” of the previous flow, or “-200” 230.
  • Flow D is represented by the difference between address “4024” of the current flow and address “3800” of the previous flow, or “+224” 232.
  • Flow E is represented by the difference between address “1024” of the current flow and address “4024” of the previous flow, or “-300” 234.
  • the baseline address “4096” uses two bytes of space 238.
  • the address offset “-96” uses one byte of space 240.
  • the address offset “-200” uses two bytes of space 242.
  • the address offset “+224” uses two bytes of space 244.
  • the address offset “-3000” uses two bytes of space 246. Consequently, transmission of the stack 204 using the address offset format 122 consumes nine bytes 248, which is a remarkable improvement compared to the forty bytes 226 used via the actual address format 202.
  • FIG. 3 A illustrates an example diagram that captures the technical benefits of using a graph 132 that represents stacks with entries, entry weight values, and/or pointers.
  • the graph generation module 114 is configured to recalculate an address for each flow in a stack using the baseline address that represents the first flow and the address offsets that represent the flows after the first flow.
  • the address serves as a flow identification (ID) (e.g., a node ID).
  • ID flow identification
  • the graph generation module 114 uses the baseline address “4096” and the address offset “-96” to recalculate the address “4000” for Flow B 228.
  • the graph generation module 114 uses the recalculated address “4000” and the address offset “-200” to recalculate the address “3800” for Flow C 230.
  • the addresses used to identify specific flows are consistent, or the same, across a fleet of machines 102(l-N), which enables the improved representation of a large number of stacks in the graph 132.
  • the graph generation module 114 is configured to sequentially read a stack file 302 (e.g., one stack at a time) when generating the graph 132. In the example of FIG. 3A, ten stacks 304, 306, 308, 310, 312, 314, 316, 318, 320, and 322 are in the stack file 302.
  • the graph 132 includes a plurality of entries 324, 326, 328, 330, which are added based on stacks that are sequentially read.
  • entry 324 is identified by the flow sequence (0, 1, 2, 3)
  • entry 326 is identified by the flow sequence (4, 2, 3)
  • entry 328 is identified by the flow sequence (5, 6, 3)
  • entry 330 is identified by the flow sequence (7, 8, 6, 3). Accordingly, each entry 324, 326, 328, 330 represents a unique sequence of flows.
  • the graph generation module 114 adds an entry to the graph.
  • the first stack 304 includes a flow sequence (0, 1, 2, 3), and thus, entry 324 identified by the flow sequence (0, 1, 2, 3) is added to the graph 132.
  • the entry 324 includes a node for flow ID 0 332, a node for flow ID 1 334, a node for flow ID 2 336, and a node for flow ID 3 338.
  • the sequence of nodes matches the flow sequence (0, 1, 2, 3).
  • entry 324 identified by the flow sequence (0, 1, 2, 3) includes a weight 340.
  • the weight 340 is a value that represents a number of times the same flow sequence is seen by the graph generation module 114. Accordingly, after reading out the first stack 304, the weight 340 is set to a value of one, but this value is incremented each time the same flow sequence (0, 1, 2, 3) is read out.
  • the graph generation module 114 For each stack that is sequentially read from the stack file 302 after the first stack 304, the graph generation module 114 is configured to determine whether the flow sequence in the stack currently being sequentially read (i.e., the “current” or “remaining” stack) matches a flow sequence in a previous stack that has already been sequentially read. Stated alternatively, the graph generation module 114 is configured to determine if the flow sequence of the current stack matches a flow sequence of an entry that already exists in the graph 132. If the flow sequence in the current stack matches a flow sequence in a previous stack, then the graph generation module 114 increments a weight value for a corresponding entry. If the flow sequence in the current stack does not match the flow sequence in any previous stack, then the graph generation module 114 adds a new entry to the graph 132.
  • the graph generation module 114 reads the second stack 306 from the stack file 302 and determines that the flow sequence of (4, 2, 3) for the second stack 306 does not match the only existing entry 324 representing the flow sequence (0, 1, 2, 3). Accordingly, entry 326 identified by the flow sequence (4, 2, 3) is added to the graph 132 and its corresponding weight 342 is set to a value of one.
  • the graph generation module 114 reads the third stack 308 from the stack file 302 and determines that the flow sequence of (5, 6, 3) for the third stack 308 neither matches the flow sequence of existing entry 324 nor the flow sequence of existing entry 326. Accordingly, entry 328 identified by the flow sequence (5, 6, 3) is added to the graph 132 and its corresponding weight 344 is set to a value of one.
  • the graph generation module 114 reads the fourth stack 310 from the stack file 302 and determines that the flow sequence of (0, 1, 2, 3) for the fourth stack 310 matches the flow sequence of existing entry 324. Accordingly, the weight 340 for entry 324 is incremented from one to two.
  • the graph generation module 114 reads the fifth stack 312 from the stack file 302 and determines that the flow sequence of (7, 8, 6, 3) for the fifth stack 312 neither matches the flow sequence of existing entry 324, the flow sequence of existing entry 326, nor the flow sequence of existing entry 328. Accordingly, entry 330 identified by the flow sequence (7, 8, 6, 3) is added to the graph 132 and its corresponding weight 346 is set to a value of one.
  • the graph generation module 114 reads the sixth stack 314 from the stack file 302 and determines that the flow sequence of (0, 1, 2, 3) for the sixth stack 314 matches the flow sequence of existing entry 324. Accordingly, the weight 340 for entry 324 is incremented from two to three.
  • the graph generation module 114 reads the seventh stack 316 from the stack file 302 and determines that the flow sequence of (4, 2, 3) for the seventh stack 316 matches the flow sequence of existing entry 326. Accordingly, the weight 342 for entry 326 is incremented from one to two.
  • the graph generation module 114 reads the eighth stack 318 from the stack file 302 and determines that the flow sequence of (0, 1 , 2, 3) for the eighth stack 318 matches the flow sequence of existing entry 324. Accordingly, the weight 340 for entry 324 is incremented from three to four
  • the graph generation module 114 reads the ninth stack 320 from the stack file 302 and determines that the flow sequence of (4, 2, 3) for the ninth stack 320 matches the flow sequence of existing entry 326. Accordingly, the weight 342 for entry 326 is incremented from two to three
  • the graph generation module 114 reads the tenth stack 322 from the stack file 302 and determines that the flow sequence of (5, 6, 3) for the tenth stack 322 matches the flow sequence of existing entry 328. Accordingly, the weight 344 for entry 328 is incremented from one to two
  • the graph 132 shows that the first entry 324 represents the first, fourth, sixth, and eighth read stacks 348, so the value for the weight 340 is four. Further, the graph 132 shows that the second entry 326 represents the second, seventh, and ninth read stacks 350, so the value for the weight 342 is three. The graph 132 shows that the third entry 328 represents the third and tenth read stacks 352, so the value for the weight 344 is two. And the graph 132 shows that the fourth entry 330 represents the fifth read stack 354, so the value for the weight 346 is one.
  • the number of stacks used in FIG. 3 A (i.e., ten) is small and is used for ease of discussion.
  • a stack file is likely to have many more stacks, and thus, a graph generated for the stack file is likely to have many more entries and larger weight values.
  • the graph generation module 114 stores the graph 132 for analysis (e.g., writes the graph 132 to disk)
  • the entries 324, 326, 328, 330 in the graph 132 are ordered according to decreasing weight values, as shown in FIG. 3 A. This ensures that entries that are seen more often in the stacks of a stack file (e.g., entries with the higher weight values or hit counts), and which are typically more important or significant from an analysis perspective, show up first when the graph 132 is being read from disk. For instance, even when a small percentage of the data in the graph has been read, a clear picture of the performance of the fleet is apparent.
  • the graph generation module 114 can additionally be configured to use a pointer from a flow identification (e.g., a flow node) in one entry of the graph to the same flow identification in a different entry in the graph.
  • a flow identification e.g., a flow node
  • the graph generation module 114 looks in entry 324 for flow identifications that match flow identifications in the new entry 326 added to the graph. Since flow ID 4 does not have a match, a node 356 is added to entry 326. However, the subsequent sequence of flow ID 2 and flow ID 3 is the same in entry 324.
  • the graph generation module 114 adds a pointer 358 from the node 356 representing flow ID 4 to the node 336 representing flow ID 2 in entry 324.
  • the flow sequence (4, 2, 3) is still intact via the pointer 358.
  • the graph generation module 114 looks in entry 324 and entry 326 for flow identifications that match flow identifications in the new entry 328 added to the graph. Since flow ID 5 and flow ID 6 do not have a match, nodes 360 and 362 are added to entry 328. However, the subsequent flow ID 3 has a match in entry 324. Consequently, to further conserve space when representing the stacks in the graph, the graph generation module 114 adds a pointer 364 from the node 362 representing flow ID 6 to the node 338 representing flow ID 3 in entry 324. The flow sequence (5, 6, 3) is still intact via the pointer 364.
  • the graph generation module 114 in response to determining that the flow sequence (7, 8, 6, 3) for the fifth stack 312 does not match the flow sequences that have already been read, the graph generation module 114 looks in entry 324, entry 326, and entry 328 for flow identifications that match flow identifications in the new entry 330 added to the graph. Since flow ID 7 and flow ID 8 do not have a match, nodes 366 and 368 are added to entry 330. However, the subsequent flow ID 6 has a match in entry 328 that represent the same flow - flow ID 6. Consequently, to further conserve space when representing the stacks in the graph, the graph generation module 114 adds a pointer 370 from the node 368 representing flow ID 8 to the node 362 representing flow ID 6 in entry 328. Thus, the flow sequence (7, 8, 6, 3) is still intact via the pointer 370 and the pointer 364.
  • FIG. 4 illustrates an example diagram that trims a graph that represents stacks with entries, entry weight values, and/or pointers.
  • the diagram in FIG. 4 is based on the diagram in FIG. 3, except that the graph is now a trimmed graph 402.
  • the graph trimming module 116 uses the weight value threshold 134 to trim the graph 132.
  • the weight value threshold is equal to three 404.
  • the weight value threshold 134 can be established based on various factors, such as a number of stacks, a number of entries, etc. Moreover, the weight value threshold 134 can be learned over time and adjusted to accommodate different analysis scenarios.
  • the graph trimming module 116 determines that entries 324 and 326 have weight values 340 and 342 that satisfy the weight value threshold of three 404 (e.g., the weight values of four 340 and three 342 are greater than or equal to the weight value threshold of three). In contrast, the graph trimming module 116 determines that entries 328 and 330 have weight values 344 and 346 that fail to satisfy the weight value threshold of three 404 (e.g., the weight values of two 344 and one 346 are less than the weight value threshold of three). Accordingly, entries 328 and 330 are not shown in the trimmed graph 402 of FIG. 4. In other words, entries 328 and 330 are removed from the graph 406. Thus, stacks 308, 312, and 322 are no longer represented in the trimmed graph 402, as captured by the “X” through these stacks in the stack file 302 in FIG. 4.
  • this trimming and/or removal can further improve the efficiency with regard to transmitting, storing, and/or processing the stack data in the graph because the removed entries are likely insignificant and/or meaningless from an analysis perspective.
  • FIG. 5A illustrates an example diagram directed to merging 502 two graphs 504, 506.
  • a first graph 504 may be generated based on stack file 124(1) and a second graph 506 may be generated based on stack file 124(2).
  • the first graph 504 comprises the trimmed graph 402 from FIG. 4, and the second graph 506 comprises another trimmed graph 508.
  • trimmed graph 402 and trimmed graph 508 include common entries 324 and 326, which include the same unique flows, and thus, the same nodes and 332, 334, 336, 338, 356 and the same pointer 358. Note that the trimmed graph 402 likely includes entries not included in trimmed graph, and vice versa, but this is not illustrated.
  • the difference between trimmed graph 402 and trimmed graph 508 is the weight values.
  • Trimmed graph 402 includes a weight value 340 of four for entry 324, while trimmed graph 508 includes a weight value 510 of six for entry 324.
  • trimmed graph 402 includes a weight value 342 of three for entry 326, while trimmed graph 508 includes a weight value 512 of four for entry 326.
  • the graph merging module 118 is configured to combine the weight values for common or matching entries, from multiple graphs. As shown in FIG. 5B, a merged graph 514 includes a combined weight value 516 of ten for entry 324 and a combined weight value 518 of seven for entry 326.
  • the merging can recursively occur as the collected stack data increases (e.g. more stack files 124(1-N) are received), and as a result of this recursive merging, one graph can represent a large number of stack files and/or stacks. Ultimately, this mitigates the need to maintain a database to store a large number of stacks and/or stack files. Instead, via the use of the graphs, the trimming of graphs, and/or the merging of graphs, the analysis of stacks can be scaled. For example, due to the space reductions and the removal of constraints, a graph for stacks collected from a fleet of customer machines can be placed in a customer allocated storage account.
  • the graphs can be merged together in accordance with various schedules, which enables the containment of stack permutations. For example, graphs can merge each twenty-four-hour window of time per-service in the fleet. Moreover, as the merging increases (e.g., more stack files and/or stacks are represented in a single graph), the weight value threshold used to trim the graphs can increase.
  • FIG. 6 illustrates an example diagram in which playback data is associated with each node in a graph.
  • FIG. 6 illustrates the trimmed graph from FIG. 4, where each node 332, 334, 336, 338, and 356 includes playback data 602.
  • the playback data 602 includes a timestamp associated with execution of a flow, as well as properties associated with the execution of the flow.
  • Example properties include a process identification (PID) and/or a thread identification (TID).
  • PID process identification
  • TID thread identification
  • the timestamp and the properties can be used to replay the execution of flows at a particular machine.
  • the playback data 602 is stored and read from a different location in the graph. Each playback data entry points to a node in the graph.
  • a timestamp 604 and properties 606 are registered for each time that flow ID 0332 is executed (e.g., at least four times in this example).
  • a timestamp 608 and properties 610 are registered for each time that flow ID 2336 is executed (e.g., at least seven times in this example).
  • a timestamp 612 and properties 614 are registered for each time that flow ID 3 338 is executed (e.g., at least seven times in this example).
  • a timestamp 616 and properties 618 are registered for each time that flow ID 4 356 is executed (e.g., at least three times in this example).
  • the machine accesses a stack to be transmitted to a stack analysis service.
  • the machine represents the first flow of the stack using an actual address.
  • the machine represents each flow of the stack after the first flow using an address offset.
  • the machine variable bit encodes the stack for transmission.
  • FIG. 8 is an example flow diagram showing aspects of a method 800 implemented by a stack analysis service to generate a graph that represent stacks in a stack file.
  • the stack analysis service receives a stack file that contains stacks.
  • the stack analysis service calculates flow (e.g., node) identifications (e.g., addresses) for the flows in each stack using the baseline address and the address offset(s).
  • the stack analysis service adds an entry to a graph for the first stack sequentially read from the stack file.
  • the stack analysis service determines whether a remaining stack (e.g., a current stack being read) matches a previous stack. If the determination at operation 808 is yes (i.e., the remaining stack matches the previous stack, and thus, an entry for the remaining stack already exists in the graph), then at operation 810 a corresponding weight value for the entry associated with the remaining stack and the previous stack is incremented. The process then returns to operation 808 for the next stack to be read. If the determination at operation 808 is no (i.e., the remaining stack does not match any previous stack, and thus, an entry for the remaining stack does not already exists in the graph), then at operation 812 a new entry is added to the graph. The process then returns to operation 808 for the next stack to be read. When there are no more stacks to in the stack file to evaluate with regard to operation 808, as captured by 814, the stack analysis service proceeds to use a weight value threshold to trim the graph at operation 816.
  • a weight value threshold to trim the graph at operation 816.
  • FIG. 9 shows additional details of an example computer architecture 900 for a device, such as a computer or a server capable of executing computer instructions (e.g., a component described herein).
  • the computer architecture 900 illustrated in FIG. 9 includes processing unit(s) 902, a system memory 904, including a random-access memory 906 (RAM) and a read-only memory (ROM) 908, and a system bus 910 that couples the memory 904 to the processing unit(s) 902.
  • the processing units 902 may also comprise or be part of a processing system. In various examples, the processing units 902 of the processing system are distributed. Stated another way, one processing unit 902 of the processing system may be located in a first location (e.g., a rack within a datacenter) while another processing unit 902 of the processing system is located in a second location separate from the first location.
  • Processing unit(s) 902 can represent, for example, a CPU-type processing unit, a GPU-type processing unit, a field-programmable gate array (FPGA), another class of digital signal processor (DSP), or other hardware logic components that may, in some instances, be driven by a CPU.
  • FPGA field-programmable gate array
  • DSP digital signal processor
  • illustrative types of hardware logic components that can be used include Application-Specific Integrated Circuits (ASICs), Application-Specific Standard Products (ASSPs), System-on-a-Chip Systems (SOCs), Complex Programmable Logic Devices (CPLDs), and the like.
  • ASICs Application-Specific Integrated Circuits
  • ASSPs Application-Specific Standard Products
  • SOCs System-on-a-Chip Systems
  • CPLDs Complex Programmable Logic Devices
  • the computer architecture 900 further includes a mass storage device 912 for storing an operating system 914, application(s) 916, modules 918, and other data described herein.
  • the mass storage device 912 is connected to processing unit(s) 902 through a mass storage controller connected to the bus 910.
  • the mass storage device 912 and its associated computer- readable media provide non-volatile storage for the computer architecture 900.
  • computer-readable media can be any available computer-readable storage media or communication media that can be accessed by the computer architecture 900.
  • Computer-readable media includes computer-readable storage media and/or communication media.
  • Computer-readable storage media includes one or more of volatile memory, nonvolatile memory, and/or other persistent and/or auxiliary computer storage media, removable and non- removable computer storage media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data.
  • computer storage media includes tangible and/or physical forms of media included in a device and/or hardware component that is part of a device or external to a device, including RAM, static RAM (SRAM), dynamic RAM (DRAM), phase change memory (PCM), ROM, erasable programmable ROM (EPROM), electrically EPROM (EEPROM), flash memory, compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), optical cards or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage, magnetic cards or other magnetic storage devices or media, solid-state memory devices, storage arrays, network attached storage, storage area networks, hosted computer storage or any other storage memory, storage device, and/or storage medium that can be used to store and maintain information for access by a computing device.
  • RAM random access memory
  • SRAM static RAM
  • DRAM dynamic RAM
  • PCM phase change memory
  • ROM erasable programmable ROM
  • EEPROM electrically EPROM
  • flash memory compact disc read-only memory
  • CD-ROM compact disc read-only memory
  • communication media can embody computer- readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism.
  • computer storage media does not include communication media. That is, computer-readable storage media does not include communications media consisting solely of a modulated data signal, a carrier wave, or a propagated signal, per se.
  • the computer architecture 900 may operate in a networked environment using logical connections to remote computers through the network 920.
  • the computer architecture 900 may connect to the network 920 through a network interface unit 922 connected to the bus 910.
  • the processing unit(s) 902 may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the processing unit(s) 902 may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the processing unit(s) 902 by specifying how the processing unit(s) 902 transition between states, thereby transforming the transistors or other discrete hardware elements constituting the processing unit(s) 902.
  • Example Clause A a method comprising: receiving a stack file that includes a plurality of stacks, wherein each stack in the plurality of stacks includes a sequence of flows; generating a graph for the stack file by sequentially reading the plurality of stacks from the stack file, the graph including a plurality of entries and each entry of the plurality of entries represents a unique sequence of flows, wherein the generating the graph includes: adding a first entry to the graph, the first entry representing the sequence of flows in a first stack of the plurality of stacks; for a remaining stack of the plurality of stacks after the first stack: determining that a particular sequence of flows included in the remaining stack of the plurality of stacks matches a previous sequence of flows included in a previous stack of the plurality of stacks; and based on the determining that the particular sequence of flows included in the remaining stack matches the previous sequence of flows included in the previous stack, incrementing, for a corresponding entry included in the graph
  • Example Clause B the method of Example Clause A, wherein removing the particular entry from the graph produces a trimmed graph, the method further comprising writing remaining entries of the trimmed graph to memory in order of decreasing weight values.
  • Example Clause C the method of Example Clause A or Example Clause B, further comprising merging the graph with another graph by combining the weight values for matching entries.
  • Example Clause D the method of any one of Example Clauses A through C, wherein: each stack of the plurality of stacks is received in a format that represents a first flow in the sequence of flows using an address and each flow in the sequence of flows after the first flow uses an address offset from a previous flow in the sequence of flows; and the method further comprises: recalculating an address for each flow in the sequence of flows using the address that represents the first flow and at least one address offset that represents each flow after the first flow; and using the address for each flow as a flow identification in the graph.
  • Example Clause E the method of Example Clause D, wherein the format variable bit encodes the address and the address offset.
  • Example Clause F the method of any one of Example Clauses A through E, wherein the graph includes playback data that includes a timestamp for each time a flow is executed and that identifies a thread identification or a process identification associated with each time the flow is executed.
  • Example Clause G a method comprising: receiving a stack file that includes a plurality of stacks, wherein each stack in the plurality of stacks includes a sequence of flows; generating a graph for the stack file by sequentially reading the plurality of stacks from the stack file, the graph including a plurality of entries and each entry of the plurality of entries represents a unique sequence of flows, wherein the generating the graph includes: adding a first entry to the graph, the first entry representing the sequence of flows in a first stack of the plurality of stacks; for a remaining stack of the plurality of stacks after the first stack: determining that a particular sequence of flows included in the remaining stack of the plurality of stacks does not match a previous sequence of flows included in a previous stack of the plurality of stacks; and based on the determining that the particular sequence of flows included in the remaining stack does not match the previous sequence of flows included in the previous stack of, adding a new entry to the graph; determining that a weight value for a particular entry of the plurality of entries included
  • Example Clause I the method of Example Clause G or Example Clause H, further comprising merging the graph with another graph by combining the weight values for matching entries.
  • Example Clause J the method of any one of Example Clauses G through I, wherein: each stack of the plurality of stacks is received in a format that represents a first flow in the sequence of flows using an address and each flow in the sequence of flows after the first flow uses an address offset from a previous flow in the sequence of flows; and the method further comprises: recalculating an address for each flow in the sequence of flows using the address that represents the first flow and at least one address offset that represents each flow after the first flow; and using the address for each flow as a flow identification in the graph.
  • Example Clause K the method of Example Clause J, wherein the format variable bit encodes the address and the address offset.
  • Example Clause L the method of any one of Example Clauses G through K, further comprising: based on the determining that the particular sequence of flows included in the remaining stack does not match the previous sequence of flows included in the previous stack, determining that a remaining flow identification included in the remaining stack matches a previous flow identification included in the previous stack; and adding a pointer from the new entry to an existing entry that includes the previous flow identification.
  • Example Clause M the method of any one of Example Clauses G through L, wherein the graph includes playback data that includes a timestamp for each time a flow is executed and that identifies a thread identification or a process identification associated with each time the flow is executed.
  • Example Clause N a system comprising: a processing system; and computer-readable storage media storing instructions that, when executed by the processing system, cause the system to: generate a graph for a stack file that includes a plurality of stacks by sequentially reading the plurality of stacks from the stack file, wherein: each stack in the plurality of stacks includes a sequence of flows; the graph includes a plurality of entries; and each entry of the plurality of entries represents a unique sequence of flows and includes a weight value that represents a number of times the unique sequence of flows occurs in the stack file; determine that a weight value for an entry of the plurality of entries fails to satisfy a weight value threshold; and remove the entry from the graph based on the determining that the weight value for the entry fails to satisfy the weight value threshold.
  • Example Clause O the system of Example Clause N, wherein removing the entry from the graph produces a trimmed graph, and the instructions further cause the system to write remaining entries of the trimmed graph to memory in an order of decreasing weight values.
  • Example Clause P the system of Example Clause N or Example Clause O, wherein the instructions further cause the system to merge the graph with another graph by reading and combining the weight values for the entries.
  • Example Clause Q the system of any one of Example Clauses N through P, wherein: each stack of the plurality of stacks is received in a format that represents a first flow in the sequence of flows using an address and each flow in the sequence of flows after the first flow uses an address offset from a previous flow in the sequence of flows; and the instructions further cause the system to: recalculate an address for each flow in the sequence of flows using the address that represents the first flow and at least one address offset that represents each flow after the first flow; and use the address for each flow as a flow identification in the graph.
  • Example Clause R the system of Example Clause Q, wherein the format variable bit encodes the address and the address offset.
  • Example Clause S the system of any one of Example Clauses N through R, wherein the graph includes playback data that includes a timestamp for each time a flow is executed and that identifies a thread identification or a process identification associated with each time the flow is executed.
  • Example Clause T the system of any one of Example Clauses N through S, wherein the instructions further cause the system to receive the stack file from a machine.
  • any reference to “first,” “second,” etc. elements within the Summary and/or Detailed Description is not intended to and should not be construed to necessarily correspond to any reference of “first,” “second,” etc. elements of the claims. Rather, any use of “first” and “second” within the Summary, Detailed Description, and/or claims may be used to distinguish between two different instances of the same element (e.g., two different stacks)

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention divulgue des techniques qui mettent en œuvre un format amélioré pour transmettre des piles d'appels (appelées dans la description piles) depuis des machines à un service d'analyse de pile. En outre, les techniques mettent en œuvre une manière améliorée pour le service d'analyse de pile de représenter le grand nombre de piles. Le format amélioré permet que la collection d'un grand nombre de piles (par exemple, des millions ou même des billions de piles) soit plus efficace. La représentation améliorée d'un grand nombre de piles permet que l'analyse soit plus efficace. Par conséquent, les techniques décrites dans la présente invention réduisent l'empreinte carbone pour une organisation qui fait fonctionner un groupe de machines car moins de ressources de réseau, de stockage et/ou de traitement sont nécessaires pour collecter et analyser un grand nombre de piles.
PCT/US2023/028306 2022-08-31 2023-07-21 Collecte et représentation de piles d'appels de programme WO2024049570A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202263402902P 2022-08-31 2022-08-31
US63/402,902 2022-08-31
US18/087,652 US20240069879A1 (en) 2022-08-31 2022-12-22 Collection and representation of program call stacks
US18/087,652 2022-12-22

Publications (1)

Publication Number Publication Date
WO2024049570A1 true WO2024049570A1 (fr) 2024-03-07

Family

ID=87569958

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/028306 WO2024049570A1 (fr) 2022-08-31 2023-07-21 Collecte et représentation de piles d'appels de programme

Country Status (1)

Country Link
WO (1) WO2024049570A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170322861A1 (en) * 2016-05-09 2017-11-09 Oracle International Corporation Compression techniques for encoding stack trace information
US20180101466A1 (en) * 2016-10-11 2018-04-12 Green Hills Software, Inc. Systems and Methods for Summarization and Visualization of Trace Data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170322861A1 (en) * 2016-05-09 2017-11-09 Oracle International Corporation Compression techniques for encoding stack trace information
US20180101466A1 (en) * 2016-10-11 2018-04-12 Green Hills Software, Inc. Systems and Methods for Summarization and Visualization of Trace Data

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"WODA 2003 ICSE Workshop on Dynamic Analysis - ICSE'03 International Conference on Software Engineering Portland", 9 May 2003, Portland, Oregon, article ABDELWAHAB HAMOU-LHADJ ET AL: "An Efficient Algorithm for Detecting Patterns in Traces of Procedure Calls", pages: 33 - 36, XP055501253 *
ANONYMOUS: "Pointer (computer programming) - Wikipedia", 30 June 2011 (2011-06-30), XP055362973, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Pointer_(computer_programming)&oldid=437038098> [retrieved on 20170407] *
ANONYMOUS: "Variable-width encoding - Wikipedia", 4 July 2022 (2022-07-04), pages 1 - 4, XP093090286, Retrieved from the Internet <URL:https://web.archive.org/web/20220704103219/https://en.wikipedia.org/wiki/Variable-width_encoding> [retrieved on 20231010] *

Similar Documents

Publication Publication Date Title
US10713589B1 (en) Consistent sort-based record-level shuffling of machine learning data
US20170123676A1 (en) Reference Block Aggregating into a Reference Set for Deduplication in Memory Management
CN111444196B (zh) 块链式账本中全局状态的哈希的生成方法、装置及设备
CN111444192B (zh) 块链式账本中全局状态的哈希的生成方法、装置及设备
CN111881012A (zh) 一种日志记录方法、装置、设备及存储介质
US20170123677A1 (en) Integration of Reference Sets with Segment Flash Management
US10334011B2 (en) Efficient sorting for a stream processing engine
CN112416654B (zh) 一种数据库日志重演方法、装置、设备及存储介质
US20240069879A1 (en) Collection and representation of program call stacks
CN111026736B (zh) 数据血缘管理方法及装置、数据血缘解析方法及装置
CN113010477A (zh) 持久内存文件系统元数据的检索方法和装置、存储结构
US10262000B1 (en) Global distributed file append using log-structured file system
WO2024049570A1 (fr) Collecte et représentation de piles d&#39;appels de programme
US20230031224A1 (en) Log compression
US11620270B2 (en) Representing and managing sampled data in storage systems
CN112559536B (zh) 一种工业设备数据的处理方法及系统
US8819355B2 (en) Information processing apparatus, information processing method, and program
CN108140047B (zh) 数据处理装置和方法以及数据容器结构
US10726870B2 (en) Timing index writes to a tape medium
CN112699129A (zh) 一种数据处理系统、方法及装置
CN111782588A (zh) 一种文件读取方法、装置、设备和介质
US10282243B2 (en) Performance enhancement for platform data dump collection
US11841865B2 (en) Database management system and associated methods
US20230315682A1 (en) Long term and short term data management of a file based time series database populated with data collected by an energy sensor for a power generating device or from another data source
US11861206B1 (en) Garbage collection for object-based storage systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23754049

Country of ref document: EP

Kind code of ref document: A1