|
CODE
|
DESCRIPTION
|
|
200
|
OK. The
request has successfully executed. Response depends upon the verb invoked.
|
|
201
|
Created. The request has
successfully executed and a new resource has been created in the process. The
response body is either empty or contains a representation containing URIs
for the resource created. The Location header in the response should point to
the URI as well.
|
|
202
|
Accepted. The
request was valid and has been accepted but has not yet been processed. The
response should include a URI to poll for status updates on the request. This
allows asynchronous REST requests
|
|
204
|
No Content. The request was
successfully processed but the server did not have any response. The client
should not update its display.
|
|
301
|
Moved
Permanently. The requested resource is no longer located at the specified
URL. The new Location should be returned in the response header. Only GET or
HEAD requests should redirect to the new location. The client should update
its bookmark if possible.
|
|
302
|
Found. The requested resource
has temporarily been found somewhere else. The temporary Location should be
returned in the response header. Only GET or HEAD requests should redirect to
the new location. The client need not update its bookmark as the resource may
return to this URL.
|
|
303
|
See Other.
This response code has been reinterpreted by the W3C Technical Architecture
Group (TAG) as a way of responding to a valid request for a non-network
addressable resource. This is an important concept in the Semantic Web when
we give URIs to people, concepts, organizations, etc. There is a distinction
between resources that can be found on the Web and those that cannot. Clients
can tell this difference if they get a 303 instead of 200. The redirected
location will be reflected in the Location header of the response. This
header will contain a reference to a document about the resource or perhaps
some metadata about it.
|
|
405
|
Method Not Allowed.
|
|
406
|
Not
Acceptable.
|
|
410
|
Gone.
|
|
411
|
Length
Required.
|
|
412
|
Precondition Failed.
|
|
413
|
Entity Too
Large.
|
|
414
|
URI Too Long.
|
|
415
|
Unsupported
Media Type.
|
|
417
|
Expectation Failed.
|
|
500
|
Internal
Server Error.
|
|
501
|
Not Implemented.
|
|
503
|
Service
Unavailable.
|
Unix Server ( Edge Node ) hangs when there are many jobs running on hadoop cluster started from Unix Edge Node.
When a unix server or an edge node is running lots of jobs (like Spark, Hadoop, or custom batch processes), crashes happen. For example. For example a process might hit a segementation fault, memory issue or ay other runtime issue. By default, if ulimit -c is not 0, the OS will create core dump. Core dump are written to disk and can be very large, sometimes hundreds of MBs or even GBs per process. What we realized was that when multiple processes crash at the same time, the system suddenly tries to write core files to disk. This was leading to DisK I/O spikes. Thus, node was becoming unresponsive. This was also leading CPU spike because OS was handling crash logging. Setting "ulimit -c 0" disables core dumps. This way we lose ability to debug crashes via core dump But, kept production edge nodes stable. On most Linux systems, by default, "core dumps" are written in current working directory of the process that crashes. Linux allows you to change core dump file nam...
Comments
Post a Comment