This slide talk about more details about Docker and what is Docker Swarm mode.
There are also some examples in this slide, you can follow them to practice.
This slide talk about more details about Docker and what is Docker Swarm mode.
There are also some examples in this slide, you can follow them to practice.
The document provides an overview of how to read and understand garbage collection (GC) log lines from different Java vendors and JVM versions. It begins by explaining the parts of a basic GC log line for the OpenJDK GC log format. It then discusses GC log lines for G1 GC and CMS GC in more detail. Finally, it shares examples of GC log formats from IBM JVMs and different levels of information provided. The document aims to help readers learn to correctly interpret GC logs and analyze GC behavior.
This document provides an overview of troubleshooting streaming replication in PostgreSQL. It begins with introductions to write-ahead logging and replication internals. Common troubleshooting tools are then described, including built-in views and functions as well as third-party tools. Finally, specific troubleshooting cases are discussed such as replication lag, WAL bloat, recovery conflicts, and high CPU recovery usage. Throughout, examples are provided of how to detect and diagnose issues using the various tools.
A 2015 performance study by Brendan Gregg, Nitesh Kant, and Ben Christensen. Original is in https://github.com/Netflix-Skunkworks/WSPerfLab/tree/master/test-results
G1 Garbage Collector: Details and TuningSimone Bordet
This document provides an overview and details about the G1 garbage collector in Java. It begins with introductions of the author and an overview of G1. Key points include that G1 is designed to provide low pause times, works well with large heap sizes, and will become the default collector in JDK 9. The document then discusses various aspects of G1 including its memory layout using regions, young generation collection, remembered set and write barrier for tracking references, and concurrent marking approach for old generation collection. It provides advice on G1 logging, tuning and common issues. An example migration from CMS to G1 for an online chess application is also summarized.
ISO SQL:2016 introduced Row Pattern Matching: a feature to apply (limited) regular expressions on table rows and perform analysis on each match. As of writing, this feature is only supported by the Oracle Database 12c.
Java Performance Analysis on Linux with Flame GraphsBrendan Gregg
This document discusses using Linux perf_events (perf) profiling tools to analyze Java performance on Linux. It describes how perf can provide complete visibility into Java, JVM, GC and system code but that Java profilers have limitations. It presents the solution of using perf to collect mixed-mode flame graphs that include Java method names and symbols. It also discusses fixing issues with broken Java stacks and missing symbols on x86 architectures in perf profiles.
SREcon 2016 Performance Checklists for SREsBrendan Gregg
Talk from SREcon2016 by Brendan Gregg. Video: https://www.usenix.org/conference/srecon16/program/presentation/gregg . "There's limited time for performance analysis in the emergency room. When there is a performance-related site outage, the SRE team must analyze and solve complex performance issues as quickly as possible, and under pressure. Many performance tools and techniques are designed for a different environment: an engineer analyzing their system over the course of hours or days, and given time to try dozens of tools: profilers, tracers, monitoring tools, benchmarks, as well as different tunings and configurations. But when Netflix is down, minutes matter, and there's little time for such traditional systems analysis. As with aviation emergencies, short checklists and quick procedures can be applied by the on-call SRE staff to help solve performance issues as quickly as possible.
In this talk, I'll cover a checklist for Linux performance analysis in 60 seconds, as well as other methodology-derived checklists and procedures for cloud computing, with examples of performance issues for context. Whether you are solving crises in the SRE war room, or just have limited time for performance engineering, these checklists and approaches should help you find some quick performance wins. Safe flying."
Delivered as plenary at USENIX LISA 2013. video here: https://www.youtube.com/watch?v=nZfNehCzGdw and https://www.usenix.org/conference/lisa13/technical-sessions/plenary/gregg . "How did we ever analyze performance before Flame Graphs?" This new visualization invented by Brendan can help you quickly understand application and kernel performance, especially CPU usage, where stacks (call graphs) can be sampled and then visualized as an interactive flame graph. Flame Graphs are now used for a growing variety of targets: for applications and kernels on Linux, SmartOS, Mac OS X, and Windows; for languages including C, C++, node.js, ruby, and Lua; and in WebKit Web Inspector. This talk will explain them and provide use cases and new visualizations for other event types, including I/O, memory usage, and latency.
Talk for AWS re:Invent 2014. Video: https://www.youtube.com/watch?v=7Cyd22kOqWc . Netflix tunes Amazon EC2 instances for maximum performance. In this session, you learn how Netflix configures the fastest possible EC2 instances, while reducing latency outliers. This session explores the various Xen modes (e.g., HVM, PV, etc.) and how they are optimized for different workloads. Hear how Netflix chooses Linux kernel versions based on desired performance characteristics and receive a firsthand look at how they set kernel tunables, including hugepages. You also hear about Netflix’s use of SR-IOV to enable enhanced networking and their approach to observability, which can exonerate EC2 issues and direct attention back to application performance.
Linux 4.x Tracing Tools: Using BPF SuperpowersBrendan Gregg
Talk for USENIX LISA 2016 by Brendan Gregg.
"Linux 4.x Tracing Tools: Using BPF Superpowers
The Linux 4.x series heralds a new era of Linux performance analysis, with the long-awaited integration of a programmable tracer: Enhanced BPF (eBPF). Formally the Berkeley Packet Filter, BPF has been enhanced in Linux to provide system tracing capabilities, and integrates with dynamic tracing (kprobes and uprobes) and static tracing (tracepoints and USDT). This has allowed dozens of new observability tools to be developed so far: for example, measuring latency distributions for file system I/O and run queue latency, printing details of storage device I/O and TCP retransmits, investigating blocked stack traces and memory leaks, and a whole lot more. These lead to performance wins large and small, especially when instrumenting areas that previously had zero visibility. Tracing superpowers have finally arrived.
In this talk I'll show you how to use BPF in the Linux 4.x series, and I'll summarize the different tools and front ends available, with a focus on iovisor bcc. bcc is an open source project to provide a Python front end for BPF, and comes with dozens of new observability tools (many of which I developed). These tools include new BPF versions of old classics, and many new tools, including: execsnoop, opensnoop, funccount, trace, biosnoop, bitesize, ext4slower, ext4dist, tcpconnect, tcpretrans, runqlat, offcputime, offwaketime, and many more. I'll also summarize use cases and some long-standing issues that can now be solved, and how we are using these capabilities at Netflix."
The document summarizes a talk on container performance analysis. It discusses identifying bottlenecks at the host, container, and kernel level using various Linux performance tools. It then provides an overview of how containers work in Linux using namespaces and control groups (cgroups). Finally, it demonstrates some example commands like docker stats, systemd-cgtop, and bcc/BPF tools that can be used to analyze containers and cgroups from the host system.
Check out my blog : https://oalieno.github.io/2019/06/07/security/pwn/rootkit/
Introduction and implementation of rootkit. Targeting linux kernel 5.x.x.
18. Kill
注意在大多数shell 下它同时也是一个内置命令
$ echo $0 && type -a kill
-bash
kill is a shell builtin
kill is /usr/bin/kill
➜ echo $0 && type -a kill
zsh
kill is a shell builtin
kill is /bin/kill
% echo $0 && type -a kill
csh
kill is a shell builtin
kill is /bin/kill
24. 守护进程对SIGHUP的处理
$ kill –s HUP pidof_nginx
“This signal [SIGHUP] is commonly used to notify
daemon processes (Chapter 13) to reread their
configuration files. The reason SIGHUP is chosen for
this is because a daemon should not have a
controlling terminal and would normally never
receive this signal.”
<<Advanced Programming in the UNIX Environment>>
53. JVM Signal Handler
scala> import sun.misc._
scala> Signal.handle(new Signal("INT"),
| new SignalHandler(){
| def handle(sig:Signal){ println("down") }}
| )
$ kill -s INT `pidof java`
scala> down // 被捕获,进程不会退出
54. JVM Signal Handler
注意,被OS或JVM已注册了的 Signal 不能被修改,比如 SIGQUIT、
SIGUSR1 等
scala> Signal.handle(
| new Signal("QUIT"),
| new SignalHandler(){
| def handle(sig:Signal){ println("down") }
| }
| )
java.lang.IllegalArgumentException: Signal already used by VM or OS:
SIGQUIT
at sun.misc.Signal.handle(Signal.java:166)
... 38 elided