大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺
http://csrd.aliapp.com/
阿里核心系统团队博客
巧用Systemtap注入延迟模拟IO设备抖动
当我们的IO密集型的应用怀疑设备的IO抖动，比如说一段时间的wait时间过长导致性能或其他疑难问题的时候，这个现象处理起来就比较棘手，因为硬件的抖动有偶发性很难重现或者重现的代价比较高。
幸运的是systemtap可以拯救我们。从原理上讲，我们应用的IO都是通过文件系统来访问的，不管read/write/sync都是，而且我们的文件大部分都是以buffered方式打开的。在这个模式下，如果pagecache不命中的话，就需要访问设备。 知道了这个基本的原理以后，我们就可以用万能的systemtap往vfs的读写请求中受控的注入延迟，来达到这个目的。
要点有以下几个：
1. 受控的时间点。
2. 延迟时间可控。
3. 目标设备可控。
我写了个脚本注入IO延迟，模拟ssd/fio硬件的抖动来验证是否是IO抖动会给应用造成影响，三个步骤如下：
步骤1: 编译模块
(更多…)
TFS Erasure code实现方案
TFS发展至今，集群部署总容量已超过50PB，机器数量约2700台。TFS在阿里内部主流部署方式是主集群内数据块2个副本，每个主集群配置两个备集群，分别在同城和异地机房，实际上每份数据6个副本，存储成本非常高，为了降低TFS存储成本，我们将Erasre code引入到TFS系统，本文将详细介绍TFS应用Erasure code的技术方案。
异步编码，对用户透明
目前已经应用Erasure code的分布式文件系统里，HDFS、Windows Azure等系统采用异步编码的方式，写流程和数据编码流程完全解耦；而GPFS、pangu（阿里云的分布式文件系统）等系统则是采用实时编码的方式，在数据写入时进行编码。
(更多…)
TFS的数据服务化之路
很多人可能都只知道，TFS需要配置一个特定的客户端才能访问。其实，如今通过一系列web_service的接口就可以轻松存储、获取TFS里面的数据，TFS在去年就已经实现了数据服务化。今天我们就来说说TFS的数据服务化之路。
在2012年以前，TFS有一个java和c++的客户端。最早只支持小文件的时候，TFS的客户端只需要在读写流程中和NameServer以及DataServer交互即可。后来在客户端实现了文件去重和大文件的支持。随着应用的增长、数据规模扩大以及跨机房容灾的需要，我们引入了RcServer来对应用、集群进行管理，并在客户端实现了相应逻辑，以达到集群选择、容灾功能都对应用透明的目的，大大简化了应用的配置，降低了应用使用TFS的成本。再后来，我们在原生文件的基础上开发了新的功能，允许应用使用自己定义的文件名来进行访问，拓展了TFS的用法。至此，客户端与后端Server的交互对象又增加了两个，逻辑复杂化的趋势愈演愈烈，需要bugfix的频率也越来越高。而每次新功能或bugfix都需要将新的客户端推到所有使用TFS的应用，这个过程异常的痛苦。不知不觉间，客户端已成为限制TFS前进的一个绊脚石，客户端改革势在必行。
(更多…)
TFS新版本特性介绍
TFS新版本(tfs-2.6）的开发主要因为要将erasure code应用到TFS中，以节省存储成本。erasure code的引入，需要TFS在数据存储结构上做改变，这对于存储系统来说是非常大的改变，借着这个机会，也对TFS做了很多的优化工作，本文主要介绍2.6.0版本TFS的一些新特性。
block id升级至64位
TFS采用每个数据块(block)由一个uint32_t类型的blockid来标识，每个block 72MB，理论上单集群能支持约300PB的存储空间，但实际上并不是每个blockid都能被利用上；另外，TFS在应用erasure code后，会引入一种新的校验块（parity block）；系统设计上是直接通过blockid的值就能判断出block的类型（最高位是否为0来区分），这样就使得数据块可用的blockid范围又缩小了一半。
为了有效解决可用blockid数量不足的问题，将blockid从uint32_t升级至uint64_t；由于TFS生成的文件名里编码了blockid，升级后，生成的新文件名将比原来更长，从原来的18字节扩张到27字节。
多线程程序问题分析小结
程序的核心是逻辑，没有正确逻辑的代码算不上是程序。人脑是物理上的单核，写程序和看代码讲求一个流程，流程其实就是单核顺序执行的过程。怎么保证单核顺序的人脑写出来的多线程程序，在物理上的多核CPU上执行正确的逻辑呢？答案是根本保证不了。多线程程序运行起来就像是开跑的赛马场，谁先跑完，谁会落后，完全无法预测；有时候相互踩踏在所难免。代码里到处充斥锁和共享的内存片段，过多的随机分支和状态导致全路径覆盖的测试case几乎是不可能的。所以多线程程序最痛苦的就是运行中爆出了core，发生了逻辑中认为不可能的事情，而你要在短时间内将其重现，定位，修复，验证。
ulimit限制之nproc问题
前两天微博上的@王关胜同学问了个问题：
#ulimit问题# 关于nproc设置：centos6，内核版本是2.6.32. 默认情况下，ulimit -u的值为1024，是/etc/security/limits.d/90-nproc.conf的值限制;注释掉这个限制后，值为95044;手工设置90-nproc.conf文件，值为新设置的值。想请 问这个95044是怎么来的？
这个问题挺有意思的，这里面有二个信息点：
1. 为什么limit配置文件是 /etc/security/limits.d/90-nproc.conf 而不是其他？
2. 为什么是nproc的值95044,而不是其他。
之前我也写了些ulimit的问题的解决，参见 这里
我们来简单的做下实验：
[shell]
$ cat /etc/security/limits.d/90-nproc.conf
* soft nproc 8933
$ ulimit -u
8933
$ cat /etc/security/limits.d/90-nproc.conf #注释掉
#* soft nproc 8933
$ ulimit -u
385962
[/shell]
我们可以看出就是说当注释掉限制的话，不同的机器值是不同的。
我们先来回答第一个问题：为什么limit配置文件是 /etc/security/limits.d/90-nproc.conf 而不是其他
这个问题早些时候 杨德华 同学碰到了，也写了篇 博文 来解释redhat6下面如何激活成功教程nproc的限制，但是文章没提到这个问题。
(更多…)
Linux下如何知道文件被那个进程写
晚上朔海同学问：
一个文件正在被进程写 我想查看这个进程 文件一直在增大 找不到谁在写 使用lsof也没找到
这个问题挺有普遍性的，解决方法应该很多，这里我给大家提个比较直观的方法。
linux下每个文件都会在某个块设备上存放，当然也都有相应的inode, 那么透过vfs.write我们就可以知道谁在不停的写入特定的设备上的inode。
幸运的是systemtap的安装包里带了inodewatch.stp，位于/usr/local/share/doc/systemtap/examples/io目录下，就是用来用途的。
我们来看下代码：
[shell]
$ cat inodewatch.stp
#! /usr/bin/env stap
probe vfs.write, vfs.read
{
# dev and ino are defined by vfs.write and vfs.read
if (dev == MKDEV($1,$2) # major/minor device
&& ino == $3)
printf (“%s(%d) %s 0x%x/%u\n”,
execname(), pid(), probefunc(), dev, ino)
}
[/shell]
这个脚本的使用方法如下： stap inodewatch.stp major minor ino
下面我们构造个场景： dd不停的写入一个文件，查出这个文件的ino, 以及它所在设备的major, minor, 运行stap脚本就可以得到答案。
大话Sheepdog 2 – 对象缓存
分布式存储系统的性能一直都是众矢之的，主要是因为数据甚至元数据的存取都添加了网络层的开销。对于多拷贝的对象存储来说，甚至还有复杂的逻辑来保持各个拷贝的一致性。对于拷贝的读写，读写的优化通常是不可兼得。比如通过最终一致性(eventual consistency)优化了写，但是读的时候需要读取大于一份的拷贝，来判断是否是最新的。这些问题都导致了性能的低下。
(更多…)
大话Sheepdog 1 – 智能节点管理
Sheepdog是开源的分布式块存储项目，具有零配置、Thin-Provision、高可靠、智能节点管理、容量线性扩展、虚拟机感知(底层支持冷热迁移和快照、克隆等)、支持计算与存储混合架构的特点等，可扩展到上千级别的物理节点。开源软件如QEMU、Libvirt以及Openstack都很好的集成了对Sheepdog的支持。
本系列将手把手让读者体验Sheepdog的各种功能，并解释背后的工作机制和原理。Sheepdog目前只支持Linux的环境，对文件系统没有任何假设。本文以Ubuntu 12.04为背景，假设GIT、GCC、Autoconf以及Make等常见的编译环境已经配置好了。读者可以根据自己的环境微调命令。
(更多…)
发布者：全栈程序员-用户IM，转载请注明出处：https://javaforall.cn/170192.html原文链接：https://javaforall.cn
【正版授权，激活自己账号】： Jetbrains全家桶Ide使用，1年售后保障，每天仅需1毛
【官方授权 正版激活】： 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...