Skip to content

Instantly share code, notes, and snippets.

@renich
Last active Apr 18, 2020
Embed
What would you like to do?
jekyll to pelican parser
#!/usr/bin/env crystal
require "yaml"
file = ARGF
# first (not interested
file.gets("---")
# 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 "="
end
puts
puts
tags = yfile["tags"].as_a
puts ":tags: " + tags.join(", ")
puts
puts file.gets_to_end.strip
layout status published title tags
post
publish
true
My new blog
Personal

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
post
publish
true
OpenStack: What is the optimal number of objects per container
2016-08-24 12:59:03 -0500
GNU & Linux
FOSS
Community
English
OpenStack

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
post
publish
true
Crashing your kernel on purpose
2016-02-15 16:20:14 -0600
GNU & Linux
FOSS
HowTos
Creative Commons
English

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.

References:

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