Skip to content

Instantly share code, notes, and snippets.

Last active Apr 18, 2020
What would you like to do?
jekyll to pelican parser
#!/usr/bin/env crystal
require "yaml"
file = ARGF
# first (not interested
# content
yfile = YAML.parse( file.gets("---", true).not_nil! )
title = yfile["title"].to_s
title_size = yfile["title"].to_s.size
puts title
title_size.times do
print "="
tags = yfile["tags"].as_a
puts ":tags: " + tags.join(", ")
puts file.gets_to_end.strip
layout status published title tags
My new blog

Welcome to my new blog!

I've writen in a simple framework that generates static pages. The framework is called Jekyll.

I hope I get the hang of it soon and devise how to make it nicer to the eyes. For now, the minima theme is enough for me and I think I will hang with it for a little while.

Anyway, let's see what happens.

layout status published title date tags
OpenStack: What is the optimal number of objects per container
2016-08-24 12:59:03 -0500
GNU & Linux

Well, I just had this question and went over to #openstack @ Freenode. There, notmyname (apparently, a moderator or @ps of some kind) answered:

12:20 < notmyname> Renich: I saw you asking questions about swift earlier
12:20 < notmyname> Renich: about object count per container
12:27 < notmyname> Renich: in case you see this later, here's my answer...
12:28 < notmyname> Renich: the recommended number of objects per container in swift depends on two things: (1) how many objects you want to add per second per container and (2) what sort of hardware you have referenced in the contianer rings
12:28 < notmyname> Renich: for the second, I strongly suggest using flash. (SSDs are fine)
12:29 < notmyname> Renich: if you need to sustain eg 100 writes per second in a single container and you've got flash devices for the container storage, then you'll probably be looking at a few dozen million objects
12:30 < notmyname> Renich: but note that this is (1) write performance--reads are unaffected and (2) per container--so shard your data client-side to use lots of containers
12:31 < Renich> notmyname: yes, thanks. Your answer helps a lot. And, yeah, we're using SSDs and testing a ZFS setup actually
12:32 < notmyname> Renich: almost all of any write performance penalty in large container has been eliminated in swift over the last year. but operationally, it's still a good idea to avoid truly huge containers. you don't want to try to replicate billion-row DBs
12:32 < notmyname> Renich: oh, interesting. I'd be interested to hear what kind of performance you get with that. last I saw (but it was a long time ago) ZFS had some pretty bad performance numbers when you get it reasonably full (lots of inodes)
12:34 < notmyname> Renich: also feel free to drop by #openstack-swift if you've got further questions
12:34 < Renich> notmyname: well, we're trying it out in a very specific use case. One putter, and a lot of getters on the setup. For climatic data
12:34 < Renich> notmyname: sure thing, thanks

So, in conclusion:

  • swift doesn't suffer from a high number of objects in a container anymore.
  • Still, you want to keep it under a couple of dozen million per container.
  • You want to use SSD for everything.
layout status published title date tags
Crashing your kernel on purpose
2016-02-15 16:20:14 -0600
GNU & Linux
Creative Commons

Ok, that sounds funny, doesn't it? Well, it turns out, sometimes, you want to test your kernel dump or something of the sorts. Here's how to do it:

echo c > /proc/sysrq-trigger

This will, instanly, crash your kernel.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment