NEWS Toronto Servers Back Up [Update]

up-n-atom

DARKLY Regular
Oh, you felt the first one on dust2? That's the only one I've noticed.


Yup, maybe it was too soon to jump the gun. I'm still adamant about tuning the default kernel parameters because they're very conservative. Keep it in the back of your minds and for now enjoy your hard work to please us because size isn't everything, so they say...
 

everyth1ng

DARKLY Regular
Were the drivers were successfully updated? I'm going to jump on for a bit tonight, but I won't be able to play again until Sunday.
 

Low Budget

DGN Staff
Staff member
Yup, maybe it was too soon to jump the gun. I'm still adamant about tuning the default kernel parameters because they're very conservative. Keep it in the back of your minds and for now enjoy your hard work to please us because size isn't everything, so they say...


Gatherix
 

Shotgun Jesus

TD Admin
Staff member
Yup, maybe it was too soon to jump the gun. I'm still adamant about tuning the default kernel parameters because they're very conservative. Keep it in the back of your minds and for now enjoy your hard work to please us because size isn't everything, so they say...
sysctl.conf seems untouched.
 

up-n-atom

DARKLY Regular
sysctl.conf seems untouched.


Run "netstat -su" (udp statistics) and if you see a high number of errors to received packets then for certain begin on the journey of fine tuning, otherwise, just keep a watching it regularly. You can dump the default parameters using sysctl and grep. Some helpful links in no particular order from a quick Google search: Link 1 (Redhat), Link 2 (Oracle), Link 3 (Splunk Q/A), Link 4 (Misc.) A lot of system admins share their sysctl.conf via Github but it's really trial and error and no size fits fits all kind of thing.
 

Shotgun Jesus

TD Admin
Staff member
Run "netstat -su" (udp statistics) and if you see a high number of errors to received packets then for certain begin on the journey of fine tuning, otherwise, just keep a watching it regularly. You can dump the default parameters using sysctl and grep. Some helpful links in no particular order from a quick Google search: Link 1 (Redhat), Link 2 (Oracle), Link 3 (Splunk), Link 4 (Misc.) A lot of system admins share their sysctl.conf via Github but it's really trial and error and no size fits fits all kind of thing.
netstat -su dumped:

Code:
IcmpMsg:
    InType0: 24836
    InType3: 1624
    InType8: 9223
    OutType0: 9223
    OutType3: 17580
    OutType8: 24957
Udp:
    24316184 packets received
    18667 packets to unknown port received.
    2 packet receive errors
    24365917 packets sent
UdpLite:
IpExt:
    InMcastPkts: 70
    InBcastPkts: 894
    OutBcastPkts: 5
    InOctets: -1846785254
    OutOctets: 697570997
    InMcastOctets: 2240
    InBcastOctets: 512377
    OutBcastOctets: 313
 

up-n-atom

DARKLY Regular
netstat -su dumped:

Code:
IcmpMsg:
    InType0: 24836
    InType3: 1624
    InType8: 9223
    OutType0: 9223
    OutType3: 17580
    OutType8: 24957
Udp:
    24316184 packets received
    18667 packets to unknown port received.
    2 packet receive errors
    24365917 packets sent
UdpLite:
IpExt:
    InMcastPkts: 70
    InBcastPkts: 894
    OutBcastPkts: 5
    InOctets: -1846785254
    OutOctets: 697570997
    InMcastOctets: 2240
    InBcastOctets: 512377
    OutBcastOctets: 313

Looks good ;) As we've always been told nothing wrong on the servers end. The co-location routers could be getting overwhelmed.

EDIT:

Another statistic you can dump are those of the NIC by running ethtool -S <ethernet_device_name>. That's a capital S and the device name has historically been eth<number> eg. eth0 but that's been changing depending on the driver manufacturer. It can be retrieved using the legacy net-tools ifconfig -a or the new iproute2 ip link show. It's basically gonna give any indications of errors at the device/driver level.
 
Top