Atlantic.net performance

uname -a
ubuntu01 3.2.0-23-generic #36-Ubuntu SMP x86_64

cat /proc/cpuinfo | grep model\ name | uniq
Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz

cat /proc/cpuinfo
cpu MHz : 1200.000
cache size : 15360 KB
cpu cores : 6

ping between 1 GbE ports ~0.267mS
ping between 40GbIB ports ~0.250mS

ibping between 40GbIB ports ~0.305mS

iperf between 1 GbE ports
root@ubuntu01:~# iperf -c 209.208.8.163 -P4
------------------------------------------------------------
Client connecting to 209.208.8.163, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  6] local 209.208.8.162 port 52414 connected with 209.208.8.163 port 5001
[  3] local 209.208.8.162 port 52412 connected with 209.208.8.163 port 5001
[  4] local 209.208.8.162 port 52413 connected with 209.208.8.163 port 5001
[  5] local 209.208.8.162 port 52415 connected with 209.208.8.163 port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-10.0 sec   377 MBytes   316 Mbits/sec
[  6]  0.0-10.0 sec   194 MBytes   162 Mbits/sec
[  4]  0.0-10.0 sec   378 MBytes   316 Mbits/sec
[  3]  0.0-10.1 sec   188 MBytes   156 Mbits/sec
[SUM]  0.0-10.1 sec  1.11 GBytes   945 Mbits/sec

iperf between 40GbIB ports
root@ubuntu01:/# iperf -c 192.168.10.2 -P2
------------------------------------------------------------
Client connecting to 192.168.10.2, TCP port 5001
TCP window size:  649 KByte (default)
------------------------------------------------------------
[  4] local 192.168.10.1 port 44917 connected with 192.168.10.2 port 5001
[  3] local 192.168.10.1 port 44916 connected with 192.168.10.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  13.1 GBytes  11.3 Gbits/sec
[  3]  0.0-10.0 sec  14.5 GBytes  12.5 Gbits/sec
[SUM]  0.0-10.0 sec  27.7 GBytes  23.8 Gbits/sec
root@ubuntu01:/# iperf -c 192.168.10.2 -P3



root@ubuntu01:~# iperf -c 192.168.10.2 -P4
------------------------------------------------------------
Client connecting to 192.168.10.2, TCP port 5001
TCP window size:  649 KByte (default)
------------------------------------------------------------
[  6] local 192.168.10.1 port 44899 connected with 192.168.10.2 port 5001
[  3] local 192.168.10.1 port 44896 connected with 192.168.10.2 port 5001
[  4] local 192.168.10.1 port 44897 connected with 192.168.10.2 port 5001
[  5] local 192.168.10.1 port 44898 connected with 192.168.10.2 port 5001
[ ID] Interval       Transfer     Bandwidth
[  6]  0.0-10.0 sec  6.92 GBytes  5.94 Gbits/sec
[  3]  0.0-10.0 sec  6.90 GBytes  5.92 Gbits/sec
[  4]  0.0-10.0 sec  6.92 GBytes  5.94 Gbits/sec
[  5]  0.0-10.0 sec  6.91 GBytes  5.94 Gbits/sec
[SUM]  0.0-10.0 sec  27.6 GBytes  23.7 Gbits/sec



root@ubuntu01:/# NPtcp -h 192.168.10.2
Send and receive buffers are 16384 and 87380 bytes
(A bug in Linux doubles the requested buffer sizes)
Now starting the main loop
  0:       1 bytes   3937 times -->      0.37 Mbps in      20.62 usec
  1:       2 bytes   4849 times -->      0.74 Mbps in      20.64 usec
  2:       3 bytes   4843 times -->      1.11 Mbps in      20.68 usec
  3:       4 bytes   3223 times -->      1.46 Mbps in      20.84 usec

 79:   65533 bytes    417 times -->   4963.59 Mbps in     100.73 usec

103: 1048573 bytes     47 times -->   7880.50 Mbps in    1015.16 usec

123: 8388611 bytes      8 times -->   9577.88 Mbps in    6682.07 usec
Others have acheived ~40Gb/sec

SDP configuration

configuring SDP and running netperf tests

Performance Tuning

Comments

Post a Comment

Popular posts from this blog

Sites, Newsletters, and Blogs

BLOGS Java.net Weblogs Martin Fowler's blog Paul Graham Ruminations of a Programmer Form Follows Function Newsletters Core Java Tech Tips Enterprise Java Tech Tips JavaSpecialists.EU TheServerSide.com Sites Java.net Today Hot Java Sites CSS Zen Garden Evernote Hacker News Pragmatic Programmer
Read more

Oracle JDBC ReadTimeout QueryTimeout

If a query exceeds the oracle.jdbc.ReadTimeout without receiving any data, an exception is thrown and the connection is terminated by the Oracle driver on the client. Unfortunately the session will still be queued on the database and continue to wait for locks, hold any current locks, and complete any DML/PL*SQL procedures that are pending on the server-side of the orphaned connection. If an application, on a another connection, due to ReadTimeout exception, retries DML/PL*SQL  which requires locks, those queries will queue behind the initial DML/PL*SQL. This will increase the workload exacerbating the situation. On applications with retries, this can be observed by querying the v$session table  or gv$session on RAC and noting new sessions started periodically based on the ReadTimeout interval. The sessions may often have the same SQL_ID and/or SQL_HASH_VALUE. If stmt.setQueryTimeout(Seconds) is issued and the statement exceeds the timeout, it will atte...
Read more

Locks held on Oracle for hours after sessions abnormally terminated by node failure

If a session holds db locks and is abnormally terminated (no fin/ack), the locks will persist until the db session is closed, typically around 2 hours and 12 minutes with default network tcp_keepalive settings. Abnormally terminated does not include CTRL C or kill -9. The ojdbc6 driver apparently has a shutdown hook thread that closes the connections in graceful shutdowns. The OS apparently closes the connections when processes are killed. Abnormally terminated might include power failure, firewall failures, Out Of Memory, OS/kernel crash, network connection failure, JBoss or other server node failure, etc. This was easily reproduced by creating a  process that connected to the db and updated a record but did not commit. While the first process was waiting, a second process with a contending update was started which blocked on the first update. The first clients network cable was then disconnected. The second clients transaction waited for approximately 2 hours until the databa...
Read more