[
https://issues.apache.org/jira/browse/CASSANDRA-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13984597#comment-13984597
]
Joshua McKenzie edited comment on CASSANDRA-7001 at 4/29/14 6:04 PM:
-
While doing some win7 bare-metal vs. ubuntu 14.04 bare-metal performance
comparisons I came across the fact that my env changes broke VisualGC
functionality. Took some digging, but it turns out that
* the cygwin install I had on my previous win8 config was screwing with the
TMP/TEMP environment variables and getting in the way of .NET's invoking of
libraries from powershell. Clearing those variables wasn't strictly necessary,
and...
* if you clear TMP and TEMP before invoking a jvm, it doesn't know where to put
some files that are necessary for jps, visualgc, and likely some other
utilities to work.
I've attached a v2 that fixes that.
As for the performance front - Windows writes look to be about 6% slower than
linux at saturation. On the read front it looks like Windows is much more
CPU-heavy without memory-mapped I/O than linux - 4 HT haswell peg at 100% on 54
threads vs. linux at 181, however with memory-mapped index file I/O Windows
read performance looks surprisingly good.
I'm planning on shelving performance profiling until after cleaning up the unit
and dtests, but I wanted to have a general baseline of where we are currently
as well as confirm no performance regressions from this patch.
Edit: I should clarify - the tests vs. OSX earlier had the stress client
running on the same machine as the cassandra instance. Given Windows being
CPU-bottlenecked on buffered I/O, the # of threads on the stress client were
mucking with the results.
was (Author: joshuamckenzie):
While doing some win7 bare-metal vs. ubuntu 14.04 bare-metal performance
comparisons I came across the fact that my env changes broke VisualGC
functionality. Took some digging, but it turns out that
* the cygwin install I had on my previous win8 config was screwing with the
TMP/TEMP environment variables and getting in the way of .NET's invoking of
libraries from powershell. Clearing those variables wasn't strictly necessary,
and...
* if you clear TMP and TEMP before invoking a jvm, it doesn't know where to put
some files that are necessary for jps, visualgc, and likely some other
utilities to work.
I've attached a v2 that fixes that.
As for the performance front - Windows writes look to be about 6% slower than
linux at saturation. On the read front it looks like Windows is much more
CPU-heavy without memory-mapped I/O than linux - 4 HT haswell peg at 100% on 54
threads vs. linux at 181, however with memory-mapped index file I/O Windows
read performance looks surprisingly good.
I'm planning on shelving performance profiling until after cleaning up the unit
and dtests, but I wanted to have a general baseline of where we are currently
as well as confirm no performance regressions from this patch.
Windows launch feature parity - augment launch process using PowerShell to
match capabilities of *nix launching
---
Key: CASSANDRA-7001
URL: https://issues.apache.org/jira/browse/CASSANDRA-7001
Project: Cassandra
Issue Type: Improvement
Reporter: Joshua McKenzie
Assignee: Joshua McKenzie
Fix For: 2.1 rc1
Attachments: 7001_v1.txt, 7001_v2.txt
The current .bat-based launching has neither the logic nor robustness of a
bash or PowerShell-based solution. In pursuit of making Windows a 1st-class
citizen for C*, we need to augment the launch-process using something like
PowerShell to get as close to feature-parity as possible with Linux.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
