Sponsored Content
Special Forums UNIX and Linux Applications Infrastructure Monitoring Event processing & machine learning in monitoring system Post 302821333 by DGPickett on Friday 14th of June 2013 11:44:01 AM
Old 06-14-2013
There is some of this sort of event predition in network protocols, to detect defective or slow paths to avoid, but servers are just supposed to run, not fail, predictable or not. The two flavors of handling this are parallel redundant concurrent load division where a dead server is detected and not sent any more load until it can respond to periodic tests. Recovery from services sent to a dying server is mostly left to client retry, but some systems of transactional middleware do requeue services that do not run to final commit, so they are run on alternative servers. Of course, query services are easier to handle than churn, where you need to rollback all when there is failure, before you requeue. Some systems do not use transactions, but structure churn so it can be applied any number of times and not have duplicate side effects (history filtering or believe the last of that seq. #).
 

We Also Found This Discussion For You

1. UNIX for Dummies Questions & Answers

learning UNIX on a Windows 2000 machine?

What is the best way to learn UNIX, shell, and Perl on a Windows 2000 machine? My place of employment uses Solaris and Perl and I would like to learn some UNIX skills on my home PC. I read about "dual boots", "Microsoft Windows Services for UNIX", and "cygwin". What other free options are... (9 Replies)
Discussion started by: wolfv
9 Replies
SENSORS-DETECT(8)					      System Manager's Manual						 SENSORS-DETECT(8)

NAME
sensors-detect - detect hardware monitoring chips SYNOPSIS
sensors-detect DESCRIPTION
sensors-detect is an interactive program that will walk you through the process of scanning your system for various hardware monitoring chips, or sensors, supported by libsensors(3), or more generally by the lm_sensors tool suite. sensors-detect will look for the following devices, in order: o Sensors embedded in CPUs, south bridges and memory controllers. o Sensors embedded in Super I/O chips. o Hardware monitoring chips accessed through ISA I/O ports. o Hardware monitoring chips reachable over the SMBus or more generally any I2C bus on your system. As the last two detection steps can cause trouble on some systems, they are normally not attempted if the second detection step led to the discovery of a Super I/O chip with complete hardware monitoring features. However, the user is always free to ask for all detection steps if so is his/her wish. This can be useful if a given system has more than one hardware monitoring chip. Some vendors are known to do this, most notably Asus and Tyan. WARNING
sensors-detect needs to access the hardware for most of the chip detections. By definition, it doesn't know which chips are there before it manages to identify them. This means that it can access chips in a way these chips do not like, causing problems ranging from SMBus lockup to permanent hardware damage (a rare case, thankfully.) The authors made their best to make the detection as safe as possible, and it turns out to work just fine in most cases, however it is impossible to guarantee that sensors-detect will not lock or kill a specific system. So, as a rule of thumb, you should not run sensors- detect on production servers, and you should not run sensors-detect if can't afford replacing a random part of your system. Also, it is recommended to not force a detection step which would have been skipped by default, unless you know what you are doing. SEE ALSO
sensors(1), libsensors(3) AUTHOR
Frodo Looijaard and Jean Delvare lm-sensors 3 December 2008 SENSORS-DETECT(8)
All times are GMT -4. The time now is 05:17 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy