Kezdőlap › Fórumok › SuSE Linux › SuSE haladó › Linux tuning
- This topic has 3 hozzászólás, 3 résztvevő, and was last updated 20 years, 1 months telt el by
kayapo.
-
SzerzőBejegyzés
-
2005-04-30-22:39 #2014321
„Tuning SUSE LINUX Enterprise Server on IBM xSeries Servers”
Ilyen géped van?2005-05-04-18:57 #2014322„Tuning SUSE LINUX Enterprise Server on IBM xSeries Servers”
Ilyen géped van?
[align=right][snapback]132539[/snapback][/align]Nem, ilyen géppel még nem dolgoztam. HP ML350-es van dual Xeon, Compaq prolient dual P3, és egy névtelen P4-es gépet állítottam be így.
2005-05-17-13:53 #2014323Nem, ilyen géppel még nem dolgoztam. HP ML350-es van dual Xeon, Compaq prolient dual P3, és egy névtelen P4-es gépet állítottam be így.
[align=right][snapback]133115[/snapback][/align]Bár nem „valami friss” az írás mégis nagyon jó ATHLON64-es alaplappal, SCSI-HDD-kell is csak néhol kell változtatni, csak ajánlhatom, a hosszú hétvégén sikerül egy ilyen konfigot beállítanom, kb 20-órányi ráfordítással (kernel+gprsec+www+pop3).
2009-12-04-19:57 #1879409Találtam egy érdekes anyagot, hogyan kell belõni egy SLES szervert. 🙂
Az anyag ahogy átnéztem, nemcsak SuSE-ras, hanem általánosságban jó Linuxokra.Az anyag címe:
http://www.redbooks.ibm.com/abstracts/redp3862.html?OpenEbbõl néhány tanácsot alkalmaztam is egy intranetes web-szerverünkre (noatime stb.).
Viszont találtam benne olyan dolgokat, amelyeket nem értek, tudna valaki segíteni (akár csak egyes pontokra is) az értelmezésben?
A ***-al jelölteket már használtam, és nem okoztak gondot, sõt!Preventing a decrease in performance
The following sysctl commands are used primarily to change security settings, but they also
have the side effect of preventing a decrease in network performance. These commands are
changes to the default values in SUSE LINUX.
_ Disabling the following parameters will prevent a hacker from using a spoofing attack
against the IP address of the server:
sysctl -w net.ipv4.conf.eth0.accept_source_route=0
sysctl -w net.ipv4.conf.lo.accept_source_route=0
sysctl -w net.ipv4.conf.default.accept_source_route=0
sysctl -w net.ipv4.conf.all.accept_source_route=0
_ These commands configure the server to ignore redirects from machines that are listed as
gateways. Redirect can be used to perform attacks, so we only want to allow them from
trusted sources:
sysctl -w net.ipv4.conf.eth0.secure_redirects=1
sysctl -w net.ipv4.conf.lo.secure_redirects=1
sysctl -w net.ipv4.conf.default.secure_redirects=1
sysctl -w net.ipv4.conf.all.secure_redirects=1
In addition, you could allow the interface to accept or not accept any ICMP redirects. The
ICMP redirect is a mechanism for routers to convey routing information to hosts. For
example, the gateway can send a redirect message to a host when the gateway receives
an Internet datagram from a host on a network to which the gateway is attached. The
gateway checks the routing table to get the address of the next gateway, and the second
gateway will route the datagram’s Internet to destination on network. Disable these
redirects using the following commands:
sysctl -w net.ipv4.conf.eth0.accept_redirects=0
sysctl -w net.ipv4.conf.lo.accept_redirects=0
sysctl -w net.ipv4.conf.default.accept_redirects=0
sysctl -w net.ipv4.conf.all.accept_redirects=0
_ If this server does not act as a router, it does not need to send redirects, so they can be
disabled:
sysctl -w net.ipv4.conf.eth0.send_redirects=0
sysctl -w net.ipv4.conf.lo.send_redirects=0
sysctl -w net.ipv4.conf.default.send_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0
_ Configure the server to ignore broadcast pings or smurf attacks:
sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
Note: The swap space is not a replacement for RAM as it is stored on physical drives that
have a significantly slower access time than memory.
_ Ignore all kinds of icmp packets or pings:
sysctl -w net.ipv4.icmp_echo_ignore_all=1
_ Some routers send invalid responses to broadcast frames, and each one generates a
warning that is logged by the kernel. These responses can be ignored:
sysctl -w net.ipv4.icmp_ignore_bogus_error_responses=1Tuning in TCP and UDP
The following commands can be used for tuning servers that support a large number of
multiple connections:
_ For servers that receive many connections at the same time, the TIME-WAIT sockets for
new connections can be reused. This is useful in Web servers, for example:
sysctl -w net.ipv4.tcp_tw_reuse=1 ***
If you enable this command, you should also enable fast recycling of TIME-WAIT sockets
status:
sysctl -w net.ipv4.tcp_tw_recycle=1 ***
Figure 1-6 shows that with these parameters enabled, the number of connections is
significantly reduced. This is good for performance because each TCP transaction
maintains a cache of protocol information about each of the remote clients. In this cache,
information such as round-trip time, maximum segment size, and congestion window are
stored. For more details, review RFC 1644.
Figure 1-6 Parameters reuse and recycle enabled (left) and disabled (right)
With both
tcp_tw_reuse and
tcp_tw_recycle
enabled, the
information about
the hosts does not
have to be obtained
again and the TCP
transaction can
start immediately,
preventing the
unnecessary traffic.
tcp_tw_reuse and
tcp_tw_recycle
enabled.
tcp_tw_reuse and
tcp_tw_recycle
disabled.
_ The parameter tcp_fin_timeout is the time to hold a socket in state FIN-WAIT-2 when the
socket is closed at the server.
A TCP connection begins with a three-segment synchronization SYN sequence and ends
with a three-segment FIN sequence, neither of which holds data. By changing the
tcp_fin_timeout value, the time from the FIN sequence to when the memory can be freed
for new connections can be reduced, thereby improving performance. This value, however,
should be changed only after careful monitoring, as there is a risk of overflowing memory
because of the number of dead sockets.
sysctl -w net.ipv4.tcp_fin_timeout=30
_ One of the problems found in servers with many simultaneous TCP connections is the
large number of connections that are open but unused. TCP has a keepalive function that
probes these connections and, by default, drops them after 7200 seconds (2 hours). This
length of time may be too large for your server and may result in excess memory usage
and a decrease in server performance.
Setting it to 1800 seconds (30 minutes), for example, may be more appropriate:
sysctl -w net.ipv4.tcp_keepalive_time=1800 ***
_ Set the max OS send buffer size (wmem) and receive buffer size (rmem) to 8 MB for
queues on all protocols:
sysctl -w net.core.wmem_max=8388608
sysctl -w net.core.rmem_max=8388608
These specify the amount of memory that is allocated for each TCP socket when it is
created.
In addition, you should also use the following commands for send and receive buffers.
They specify three values: minimum size, initial size, and maximum size:
sysctl -w net.ipv4.tcp_rmem=”4096 87380 8388608″
sysctl -w net.ipv4.tcp_wmem=”4096 87380 8388608″
The third value must be the same as or less than the value of wmem_max and
rmem_max.
_ Validate the source packets by reserved path. By default, routers route everything, even
packets that obviously are not meant for this network. These packets can be dropped, by
enabling the appropriate filter:
sysctl -w net.ipv4.conf.eth0.rp_filter=1
sysctl -w net.ipv4.conf.lo.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1
sysctl -w net.ipv4.conf.all.rp_filter=1
_ When the server is heavily loaded or has many clients with bad connections with high
latency, it can result in an increase in half-open connections. This is very common for Web
servers, especially when there are many dial-up users. These half-open connections are
stored in the backlog connections queue. You should set this value to at least 4096 (the
default is 1024).
Setting this value is useful even if your server does not receive this kind of connection, as
it can still be protected from a denial-of-service (syn-flood) attack.
sysctl -w net.ipv4.tcp_max_syn_backlog=4096 ***
_ We should set the ipfrag parameters particularly for NFS and Samba servers. Here, we
can set the maximum and minimum memory used to reassemble IP fragments. When the
30 Tuning SUSE LINUX Enterprise Server on IBM Eserver xSeries Servers
value of ipfrag_high_thresh in bytes of memory is allocated for this purpose, the fragment
handler will drop packets until ipfrag_low_thres is reached.
Fragmentation occurs when there is an error during the transmission of TCP packets.
Valid packets are stored in memory (as defined with these parameters) while corrupted
packets are retransmitted.
For example, to set the range of available memory to between 256 MB and 384 MB:
sysctl -w net.ipv4.ipfrag_low_thresh=262144
sysctl -w net.ipv4.ipfrag_high_thresh=393216Kiváncsian várom a hozzászólásokat 😉
-
SzerzőBejegyzés
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz