From 0c1ceeb0a30609a105dd69e000d1c391e2d2927e Mon Sep 17 00:00:00 2001 From: Patrik Nyblom Date: Thu, 2 May 2013 18:49:45 +0200 Subject: Add system_monitor of long_schedule --- erts/doc/src/erlang.xml | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'erts/doc/src/erlang.xml') diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml index 7dc59ea954..20fc9e70f2 100644 --- a/erts/doc/src/erlang.xml +++ b/erts/doc/src/erlang.xml @@ -6058,6 +6058,49 @@ ok notice.

+ {long_schedule, Time} + +

If a process or port in the system runs uninterrupted + for at least Time wall clock milliseconds, a + message {monitor, PidOrPort, long_schedule, Info} + is sent to MonitorPid. PidOrPort is the + process or port that was running and Info is a + list of two-element tuples describing the event. In case + of a pid(), the tuples {timeout, Millis}, + {in, Location} and {out, Location} will be + present, where Location is either an MFA + ({Module, Function, Arity}) describing the + function where the process was scheduled in/out, or the + atom undefined. In case of a port(), the + tuples {timeout, Millis} and {port_op,Op} + will be present. Op will be one of proc_sig, + timeout, input, output, + event or dist_cmd, depending on which + driver callback was executing. proc_sig is an + internal operation and should never appear, while the + others represent the corresponding driver callbacks + timeout, ready_input, ready_output, + event and finally outputv (when the port + is used by distribution). The Millis value in + the timeout tuple will tell you the actual + uninterrupted execution time of the process or port, + which will always be >= the Time value + supplied when starting the trace. New tuples may be + added to the Info lists in the future, and the + order of the tuples in the list may be changed at any + time without prior notice. +

+

This can be used to detect problems with NIF's or + drivers that takes too long to execute. Generally, 1 ms + is considered a good maximum time for a driver callback + or a NIF. However, a time sharing system should usually + consider everything below 100 ms as "possible" and + fairly "normal". Schedule times above that might however + indicate swapping or a NIF/driver that is + misbehaving. Misbehaving NIF's and drivers could cause + bad resource utilization and bad overall performance of + the system.

+
{large_heap, Size}

If a garbage collection in the system results in -- cgit v1.2.3 From eb4d4c133a8c2ad00807888289cb99d67f70896f Mon Sep 17 00:00:00 2001 From: Patrik Nyblom Date: Mon, 6 May 2013 14:53:07 +0200 Subject: Minor spelling correction --- erts/doc/src/erlang.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'erts/doc/src/erlang.xml') diff --git a/erts/doc/src/erlang.xml b/erts/doc/src/erlang.xml index 20fc9e70f2..767edc1cc0 100644 --- a/erts/doc/src/erlang.xml +++ b/erts/doc/src/erlang.xml @@ -6086,12 +6086,12 @@ ok uninterrupted execution time of the process or port, which will always be >= the Time value supplied when starting the trace. New tuples may be - added to the Info lists in the future, and the + added to the Info list in the future, and the order of the tuples in the list may be changed at any time without prior notice.

This can be used to detect problems with NIF's or - drivers that takes too long to execute. Generally, 1 ms + drivers that take too long to execute. Generally, 1 ms is considered a good maximum time for a driver callback or a NIF. However, a time sharing system should usually consider everything below 100 ms as "possible" and -- cgit v1.2.3