Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

While installing Riak 1.4 I encountered some issues and thought writing down the answers might help someone else.

Following the instructions for Installing From Apt-Get, when I reached:

sudo apt-get install riak

I got this message:

Failed to fetch
http://apt.basho.com/pool/precise/main/riak_1.4.0-1_amd64.deb Size mismatch
E: Unable to fetch some archives, maybe run apt-get update or try with
–fix-missing?

Not a problem with the Riak 1.4 distribution but an error with Ubuntu.

Correct as follows:

sudo aptitude clean

(rtn)

Then;

sudo aptitude update

(rtn)

close, restart Linux

Cleans the apt cache and then the install was successful.

Post Installation Notes:

Basho suggests to start Riak with:

riak start

My results:

Unable to access /var/run/riak, permission denied, run script as root

Use:

sudo riak start

I then read:

sudo riak start
!!!!
!!!! WARNING: ulimit -n is 1024; 4096 is the recommended minimum.
!!!!

The ulimit warning is not unexpected and solutions are documented at: Open Files Limit.

As soon as I finish this session, I am going to create the file /etc/default/riak and its contents will be:

ulimit -n 65536

The file needs to be created as root.

May as well follow the instructions for “Enable PAM Based Limits for Debian & Ubuntu” in the Open Files document as well. Requires a reboot.

The rest of the tests of the node went well until I got to:

riak-admin diag

The documentation notes:

Make the recommended changes from the command output to ensure optimal node operation.

I was running in an Emacs shell so capturing the output was easy:

riak-admin diag
[critical] vm.swappiness is 60, should be no more than 0
[critical] net.core.wmem_default is 229376, should be at least 8388608
[critical] net.core.rmem_default is 229376, should be at least 8388608
[critical] net.core.wmem_max is 131071, should be at least 8388608
[critical] net.core.rmem_max is 131071, should be at least 8388608
[critical] net.core.netdev_max_backlog is 1000, should be at least 10000
[critical] net.core.somaxconn is 128, should be at least 4000
[critical] net.ipv4.tcp_max_syn_backlog is 2048, should be at least 40000
[critical] net.ipv4.tcp_fin_timeout is 60, should be no more than 15
[critical] net.ipv4.tcp_tw_reuse is 0, should be 1
[warning] The following preflists do not satisfy the n_val:
[[{0,
‘riak@127.0.0.1’},
{22835963083295358096932575511191922182123945984,
‘riak@127.0.0.1’},
{45671926166590716193865151022383844364247891968,
‘riak@127.0.0.1’}],
[approx. 376 lines omitted]
[{1438665674247607560106752257205091097473808596992,
‘riak@127.0.0.1’},
{0,
‘riak@127.0.0.1’},
{22835963083295358096932575511191922182123945984,
‘riak@127.0.0.1’}]]
[notice] Data directory /var/lib/riak/bitcask is not mounted with ‘noatime’. Please remount its disk with the ‘noatime’ flag to improve performance.

The first block of messages:

[critical] vm.swappiness is 60, should be no more than 0
[critical] net.core.wmem_default is 229376, should be at least 8388608
[critical] net.core.rmem_default is 229376, should be at least 8388608
[critical] net.core.wmem_max is 131071, should be at least 8388608
[critical] net.core.rmem_max is 131071, should be at least 8388608
[critical] net.core.netdev_max_backlog is 1000, should be at least 10000
[critical] net.core.somaxconn is 128, should be at least 4000
[critical] net.ipv4.tcp_max_syn_backlog is 2048, should be at least 40000
[critical] net.ipv4.tcp_fin_timeout is 60, should be no more than 15
[critical] net.ipv4.tcp_tw_reuse is 0, should be 1

are network tuning issues.

Basho answers the “how to correct?” question at Linux Performance Tuning but there is no link from the Post Installation Notes.

The next block of messages:

[warning] The following preflists do not satisfy the n_val:
[[{0,
‘riak@127.0.0.1’},
{22835963083295358096932575511191922182123945984,
‘riak@127.0.0.1’},
{45671926166590716193865151022383844364247891968,
‘riak@127.0.0.1’}],
[approx. 376 lines omitted]
[{1438665674247607560106752257205091097473808596992,
‘riak@127.0.0.1’},
{0,
‘riak@127.0.0.1’},
{22835963083295358096932575511191922182123945984,
‘riak@127.0.0.1’}]]

is a known issue: N Value – Preflist Message is Vague.

From the issue, the message means: “these preflists have more than one replica on the same node.”

Not surprising since I am running on one physical node and not in production.

The Riak Fast Track has you create four nodes on one physical node as a development environment. So I’m going to ignore the “prelists” warning in this context.

The last message:

[notice] Data directory /var/lib/riak/bitcask is not mounted with ‘noatime’. Please remount its disk with the ‘noatime’ flag to improve performance.

is resolved under “Mounts and Scheduler” in the Linux Performance Tuning document.

I am going to make all the system changes, reboot and start on the The Riak Fast Track tomorrow.

PS: In case you are wondering what this has to do with topic maps, ask yourself what characteristics you would want in a distributed topic map system?

Well, they actually said: Basho Announces Availability of Riak 1.4.

From the post:

We are excited to announce the launch of Riak 1.4. With this release, we have added in more functionality and addressed some common requests that we hear from customers. In addition, there are a few features available in technical preview that you can begin testing and will be fully rolled out in the 2.0 launch later this year.

The new features and updates in Riak 1.4 include:

• Secondary Indexing Improvements: Query results are now sorted and paginated, offering developers much richer semantics
• Introducing Counters in Riak: Counters, Riak’s first distributed data type, provide automatic conflict resolution after a network partition
• Simplified Cluster Management With Riak Control: New capabilities in Riak’s GUI-based administration tool improve the cluster management page for preparing and applying changes to the cluster
• Reduced Object Storage Overhead: Values and associated metadata are stored and transmitted using a more compact format, reducing disk and network overhead
• Hinted Handoff Progress Reporting: Makes operating the cluster, identifying and troubleshooting issues, and monitoring the cluster simpler
• Improved Backpressure: Riak responds with an overload message if a vnode has too many messages in queue

Plus performance and management enhancements for the enterprise crowd.

Download Riak 1.4: http://docs.basho.com/riak/latest/downloads/

Code at: Github.com/basho

Live webcast: What’s New in Riak 1.4” on July 12th.

That’s this coming Friday.

Riak 1.2 Webinar – 21st August 2012

From the registration page:

Join Basho Technologies’ Engineer, Joseph Blomstedt, for an in-depth overview of Riak 1.2, the latest version of Basho’s flagship open source database. In this live webinar, you will see changes in Riak 1.2 open source and Enterprise versions, including:

• New approach to cluster administration
• Built-in capability negotiation
• Repair Search or KV Partitions thru Riak Console
• Enhanced Handoff Reporting
• Protobuf API Support for 2i and Search indexes
• New Packaging for FreeBSD, SmartOS, and Ubuntu
• Stats Improvements
• LevelDB Improvements

I would have included this with the Riak 1.2 release post but was afraid you would not get past the download link and not see the webinar.

It’s on my calendar. How about yours?

Riak 1.2 Is Official!

From the post:

Nearly three years ago to the day, from a set of green, worn couches in a modest office Cambridge, Massachusetts, the Basho team announced Riak to the world. To say we’ve come a long way from that first release would be an understatement, and today we’re pleased to announce the release and general availability of Riak 1.2.

Here’s the tl;dr on what’s new and improved since the Riak 1.1 release:

• More efficiently add multiple Riak nodes to your cluster
• Stage and review, then commit or abort cluster changes for easier operations; plus smoother handling of rolling upgrades
• Better visibility into active handoffs
• Repair Riak KV and Search partitions by attaching to the Riak Console and using a one-line command to recover from data corruption/loss
• More performant stats for Riak; the addition of stats to Riak Search
• 2i and Search usage thru the Protocol Buffers API
• Official Support for Riak on FreeBSD
• In Riak Enterprise: SSL encryption, better balancing and more granular control of replication across multiple data centers, NAT support

If that’s all you need to know, download the new release or read the official release notes. Also, go register for RICON.

OK, but I have a question: What happened to the lucky “…green, worn couches…”? 😉

Milking Performance from Riak Search by Gary William Flake.

From the post:

The primary backend store of Clipboard is built on top of Riak, one of the lesser known NoSQLs solutions. We love Riak and are really happy with our experiences with it — both in terms of development and operations — but to get to where we are, we had to use some tricks. In this post I want to share with you why we chose Riak and also arm you with some of the best tricks that we learned along the way. Individually, these tricks gave us better than a 100x performance boost, so they may make a big difference for you too.

If you don’t know what Clipboard is, you should try it out. We’re in private beta now, but here’s a backdoor that will bypass the invitation system: Register at Clipboard.

Good discussion of term-based partitioning and its disadvantages. (Term-based partitioning being native to Riak.) Solved in part by judging likely queries in advance and precomputing inner joins. Not a bad method, depending on your confidence in your guesses about likely queries.

You will also have to determine if sorting on a primary key meets your needs, for a 10X to 100X performance gain.

The Basho blog has a couple of very good posts on vector clocks:

Why Vector Clocks are Easy

Why Vector Clocks are Hard

The problem statement was as follows:

Alice, Ben, Cathy, and Dave are planning to meet next week for dinner. The planning starts with Alice suggesting they meet on Wednesday. Later, Dave discuss alternatives with Cathy, and they decide on Thursday instead. Dave also exchanges email with Ben, and they decide on Tuesday. When Alice pings everyone again to find out whether they still agree with her Wednesday suggestion, she gets mixed messages: Cathy claims to have settled on Thursday with Dave, and Ben claims to have settled on Tuesday with Dave. Dave can’t be reached, and so no one is able to determine the order in which these communications happened, and so none of Alice, Ben, and Cathy know whether Tuesday or Thursday is the correct choice.

Vector clocks are used to keep the order of communications clear. Something you will need in distributed systems, including those for topic maps.