精华内容
下载资源
问答
  • 1. 问题描述 某机场在网络上提交业务数据时,会出现不定时和间歇性页面无法访问数据提交失败现象,过段时间后恢复正常。通过服务器业务软件看不到这些用户登陆和连接状态,而在防火墙和审计设备中能看到...

    db2c2f244369d0b9062e0ea75b356299.png

    当应用出现不能访问或者访问慢的时候,我们通常会怀疑是某个网络设备或节点设备的问题,然而本案例的分析过程告诉我们,经验往往是不准确的。

    1. 问题描述

    某机场在网络上提交业务数据时,会出现不定时和间歇性的页面无法访问和数据提交失败的现象,过段时间后恢复正常。通过服务器的业务软件看不到这些用户的登陆和连接状态,而在防火墙和审计设备中能看到用户IP地址的通信。用户无法确定是应用服务器性能的问题、网络设备的问题还是其他问题。网络拓扑图如下图(故障环境的网络拓扑图)所示。

    b5c391fc900fe4ba4c30dd4db3064f1f.png

    故障环境的网络拓扑

    说明:

    当用户使用浏览器访问业务时,会出现页面无法访问和网页显示慢的问题。正常显示页面后输入账号信息,认证通过后提交相关的数据。业务服务器将数据转发给认证检测设备,检测通过后,将相关数据写入数据库服务器。如果业务服务器与认证机检测设备交互出现问题,那么OA服务器将无法写入到数据库中。

    95bca0dceeab92501885947373bab9f6.png

    部署思路:

    页面访问慢、无法访问和错误代码等问题,都是间歇性和不定时的出现。根据传统排障经验,先从防火墙和审计设备入手,查看是否为防火墙和审计设备出现问题。其实我们要从故障的最近位置进行排障。

    网络应用性格管理分析系统可以对网络中的流量进行采集、分析、应用链关联、溯源和元数据深层分析等。所以把服务器区域的交换机进行流量镜像。分析系统部署的位置为服务器区域的交换机。

    1. 分析过程

    2.1 分析思路

    根据客户反映的问题,OA页面出现的错误代码、资源链接失效和访问慢等,要先分析是否有网络拥塞或者突发流量出现;其次是分析服务器的处理性能是否负载过大;最后分析服务器区域是否有安全事件。

    网络性能分析是通过分析客户端请求和服务器响应的流量会话数据,统计网络的延时、丢包、抖动、重传和交互数量。

    应用服务器性能分析是通过分析请求和响应的交互过程,统计服务器的响应时间、重传、交互窗口值和会话数据量等。

    服务器区域的安全事件是通过回溯对比正常时间和故障点时间的流量情况进行判断。

    如果服务器区域正常,故障点时间和其他时间都一致,可以向上排查分析、判断和论证防火墙和审计设备。

    2.2 性能分析

    错误代码和服务响应慢,从采集的数据包中分析网络和应用资源是否满足访问数量和响应请求的处理能力。从网络传输和应用资源进行统计、分析和判断故障点定位,首先统计错误代码导致的链接、数量和时延。

    ○ 错误代码500

    出现错误代码500的原因有很多,一般来说,如果程序出错,那么服务端会返回给用户一个友好的错误提示,统一称之为服务器500错误。从采集的流量中选择故障点时间段,统计出现500错误的链接、数量和IP地址。下图是应用链接500类返回码统计表

    93562b146ec8c0ceda0e746560fbe53a.png

    应用链接500类返回码统计表

    发现存在大量的服务器内部错误,通过统计表可以查到那些IP地址出现的频率多,然后对相关IP地址进行流量检索分析。

    ○错误代码400

    选择故障点点时间段,检索相关IP地址时的流量,流量会按照IP会话进行归类、分析、统计网络性能和应用性能数据,见下图(客户端和服务器交互性能)。统计出现400错误的链接、数量和IP地址。下图是应用链接400类返回码的统计表。

    c75494cfa1c11625fb6d767f153f80a6.png

    客户端和服务端交互性能

    3c84a28997676be23ac263ac8db4648a.png

    应用链接400类返回码

    通过图(客户端和服务器交互性能)发现,网络传输时间很短,说明网络传输正常。下面对应用性能资源进行分析。

    ○ 应用资源响应时间

    访问应用链接慢的问题,从采集的流量中选择故障点的时间段,在统计栏中,应用服务响应时间、慢响应出现0,如下图(应用服务区响应时间、数据传输时间和响应字节)。有响应的字节,表示成功响应过,可以排除防火墙和IPS阻断和丢弃的因素。

    响应时间为链接资源服务器响应客户端请求所使用的时间,通过下图(资源响应时间统计表)发现有的链接响应时间在数十秒级。而数据传输时间在毫秒级别。

    ede800a60f176a1b1a73ca65d73b97b4.png

    应用服务区响应时间、数据传输时间和响应字节

    3bb5019f647c9f8852a3b660f8563c4c.png

    资源响应时间统计表

    再次梳理分析,数据传输时间在微秒和纳秒,说明网络数据传输没有问题。同时客户端和服务器有数据的传输和交互,可以排除防火墙和审计设备。响应时间为客户端向应用发送请求,应用服务器响应其请求所花费的时间。通过统计表发现响应时间最大为37秒,在目前网络的快速发展下,一秒都会让客户体验到慢。

    2.1 分析结论及建议

    通过分析业务应用所返回的错误代码及资源响应时间,对比网络传输时间,说明相关应用模块处理能力不足和资源链接失效。深层解码数据包分析发现,响应资源均没有启动传输压缩机制,导致传输效率低下,响应传输时间增加。

    解决方法:

    √ 提高应用模块处理性能;

    √ 提供应用并发处理能力(如增加进程数和线程数,开启异步IO模式);

    √ 启用压缩传输。

    展开全文
  • dCache是一个系统,用于使用多种标准访问方法在单个虚拟文件系统树下存储和检索分布在大量异构服务器节点之间大量数据。 取决于持久性模型,dCache提供了与后端(第三级)存储系统交换数据以及空间管理,池吸引,...
  • 没有一个具体例子,很难想象删除数据的性质和可用的访问路径会产生大数据量删除操作对系统性能影响,所以我要把部分时间花在本文讨论两个测试生成的数据集。这篇文章似乎有点长但相当多空间会被表格占用。...

    在这个简短系列的第1部分中,我提供了两个场景的非正式描述,在这些场景中,我们可以从表中进行大规模删除。没有一个具体的例子,很难想象删除数据的性质和可用的访问路径会产生大数据量删除操作对系统的性能影响,所以我要把大部分的时间花在本文讨论的两个测试生成的数据集。这篇文章似乎有点长但相当多的空间会被表格占用。

    简单的数据集

    随着硬件的能力和规模的不断增长,我们越来越难以就“大表”或“大规模删除”的含义达成一致,对于一个人来说,100万行似乎很大,而对于另一个人来说,1亿行似乎相当普通。

    我将使用一个折中方案,用1000万行表示一个投资系统,该系统10年来以每年100万行的速度增长,并且已经达到了1.6GB的段大小。

    当然,这个表只是组成整个系统的几个表中的一个,在某个时候我们会对所需要的数据担心,但是,目前,我们只考虑这个表,只考虑表本身和表上的4个索引。

    下面是生成数据集的代码:

    execute dbms_random.seed(0)
    
    create table t1 (
        id      not null,
        date_open,  date_closed,
        deal_type,  client_ref,
        small_vc,   padding
    )
    nologging
    as
    with generator as (
        select  /*+ materialize cardinality(1e4) */
        rownum  id 
        from    dual
        connect by
            rownum <= 1e4
    )
    select
        1e4 * (g1.id - 1) + g2.id
    id,
        trunc(
            add_months(sysdate, - 120) + 
                (1e4 * (g1.id - 1) + g2.id)* 3652 / 1e7
        )                               
    date_open,
        trunc(
            add_months(
                add_months(sysdate, - 120) + 
                    (1e4 * (g1.id - 1) + g2.id) * 3652 / 1e7,
                12 * trunc(dbms_random.value(1,6))
            )
        )                               
    date_closed,
        cast(dbms_random.string('U',1) as varchar2(1))  deal_type,
        cast(dbms_random.string('U',4) as varchar2(4))  client_ref,
        lpad(1e4 * (g1.id - 1) + g2.id,10)      small_vc,
        rpad('x',100,'x')               padding
    from
        generator   g1,
        generator   g2
    where
        g1.id <= 1e3
    and     g2.id <= 1e4
    ;
    
    execute dbms_stats.gather_table_stats(user,'t1',method_opt=>'for all columns size 1')
    
    alter table t1 add constraint t1_pk primary key(id) using index nologging;
    create index t1_dt_open on t1(date_open) nologging;
    create index t1_dt_closed on t1(date_closed) nologging;
    create index t1_client on t1(client_ref) nologging;上面的输出看起来不是很明显,但是代码生成了10000万行;

    date_open:从过去的120个月(10年3652天)开始,用于增加值的算法意味着最近的条目在当前日期。

    date_closed:是添加到date_open(该表是记录定期投资的简单模型)的1到5年(包括5年)之间的整数。

    deal_type:是随机生成的单个大写字符——生成26个不同的值,这些值具有相同的数据量;

    client_ref:是随机生成的一个固定长度的字符串,由4个大写字母组成,每个组合提供大约50万个组合和20行。

    note:作为补充说明-已经生成的数据集没有使用rownum在任何地方的高容量选择;这将使我能够使用并行执行更快地生成数据(“level”和“rownum”伪列都限制了Oracle使用并行执行的能力)。但是在本例中,因为我希望id列对按到达顺序存储的按顺序生成的值进行建模,所以我是按顺序运行代码的。

    规模

    我的笔记本电脑上是在Linux 5 VM上运行了database 12.1.0.2,我得到了创建数据、收集统计数据和创建索引所花费的时间如下:

    表创建:7:06.40

    数据收集:0:10.54

    PK主键:0:10.94

    创建索引:0:10.79 (date_open)

    创建索引:0:12.17 (date_closed)

    创建索引:0:13.65 (client_ref)

     当然,这就要我们开始提一个很现实问题,即不同的系统可能会有不同的时间消耗结果。

    虚拟机分配4 gb的内存(1.6 gb是留出memory_target)和一个四核CPU 2.8 ghz 的CPU,但可能最重要的是机器1 tb的固态盘,所以不会失去太多时间在物理I / O。

    数据库配置了3个重做日志组,每个重做日志组的大小为200MB(为了日志文件检查点和日志文件切换等待出现一些延迟),日志是重复的,但是实例没有在archivelog模式下运行。

    在stats收集之后,大多数块中的表块计数大约为204,000个块,每个块有49行,PK索引和client_ref索引大约有22,000个叶块,两个日期索引大约有26,500个叶块。

    Quality

    当使用这样的模型来质疑它们与现实生产中有多接近时是非常重要的。到目前来看,在我所的的准备工作中,你能发现其中存在哪些问题呢?

    首先,表中的Id列太完美了,id列在表中的顺序从小到大排列的非常有序,然而在现实当中,并发性的插入会有一点都抖动,一定范围内连续性的值可能分布在少量的块上,这可能不是很重要,重要的是我是在创建表之后插入数据才创建的索引,这意味着索引在物理上来看是没有什么问题。(每个块中有10%的自由空间),我应该先创建一张空的表,然后在表上建立索引,在这之后再运行几个并发性的脚本使用序列进行单行插入来生成id,但是我上次这样创建的时候,所需要的时间增加了40倍。同样的,这可能也不是很重要,我记得在生产系统中索引的叶块中平均可用空间在任何时候都接近30%。 随着块与块之间明显的变化差异,我想时不时的通过基于叶块状态的检查,尤其是date_open这个索引。 

    场景

    尽管任何时间消耗都取决于机器的配置和资源的分配,并且这个模型过于简单化,但是我们任然可以从一些基本的测试当中获取一些有意思的信息。让我们从几个与业务相关的的场景开始: 

    a、删除所有5年前完成的交易

    b、删除client_ref以“A”-“E”开头的所有交易

    c、删除所有5年以上的交易

    a项可能在删除前已经做了一次最基本要求的归档,也可能已经cpye 到另一张表中了。

    b项可能告诉我们,client_ref已经(ab)用于在第一个字母中为引用编码一些重要的分类,我们将数据分成两个处理集。

    c项可能是按照date_open 对数据进行分区的过程的一部分。(虽然我不确定在这种情况下分区是不是一个好方法),在做任何对于数据库来说影响比较大的操作之前,最好看看时刻能够可视化的知道oracle将要做什么?执行的步骤是什么,以及工作负载会出现在哪里?这些场景都是相同的吗?如果不是,他们有什么不同?如果你不知道你的数据以及你删除数据的影响,你可以从数据库中寻求答案-举个例子:

    select
            rows_in_block,
            count(*)                                     blocks,
            rows_in_block * count(*)                     row_count,
            sum(count(*)) over (order by rows_in_block)                 running_blocks,
            sum(rows_in_block * count(*)) over (order by rows_in_block) running_rows
     from
            (
            select
                    dbms_rowid.rowid_relative_fno(rowid),
                    dbms_rowid.rowid_block_number(rowid),
                     count(*)                                 rows_in_block
            from
                     t1
     --
     --     where   date_open >=add_months(sysdate, -60)
     --     where   date_open <  add_months(sysdate, -60)
     --
     --     where   date_closed >=add_months(sysdate, -60)
     --     where   date_closed <  add_months(sysdate, -60)
     --
     --     where  substr(client_ref,2,1)  >= 'F'
     --     where  substr(client_ref,2,1)  < 'F'
     --
            group by
                    dbms_rowid.rowid_relative_fno(rowid),
                     dbms_rowid.rowid_block_number(rowid)
            )
     group by
            rows_in_block
     order by
            rows_in_block
     ;

     您将注意到,在这个查询中,我有六个注释谓词(在三个互补对中)。这个查询的基本目的是让我总结一下有多少块可以容纳多少行。但是每对谓词都让我对每种场景的效果有了一些想法-每一对中的一个告诉我关于将要删除的数据量和模式的一些信息。下面是sql*plus

    中执行如上查询的输出:

                                                  Blocks            Rows
    Rows per block   Blocks         Rows   Running total   Running total
    -------------- -------- ------------   -------------   -------------
               27        1           27               1              27
               49  203,877    9,989,973         203,878       9,990,000
               50      200       10,000         204,078      10,000,000
                   --------
    sum             204,078

    下面的输出显示了如果删除了5年以上打开的数据行,留下来的数据将会是什么样子?(也就是说,使用谓词date_open >= add_months(sysdate, -60))

                                                 Blocks          Rows
    Rows per block   Blocks          Rows Running total Running total
    -------------- -------- ------------- ------------- -------------
                27        1            27             1            27
                42        1            42             2            69
                49  102,014     4,998,686       102,016     4,998,755
                   --------
    sum             102,016

    这看起来相当不错--粗略的来说我们已经将表一半的块清空了,另一半没有动。如果我们现在尝试‘收缩空间’,那么我们只需要将表的下半部分复制到表的上半部分。我们会生成大量的undo数据和redo日志。但是任何索引的任何聚簇因子可能没有一点改变。另一种选择是,如果我们决定让空白空间保持原样,那么任何新数据都会非常有效地开始填充空白空间(几乎就想是重新分配区一样),同样的我们也会看到任何聚簇的因子也没有什么改变。将此结果与删除所有5年前关闭的行所带来的结果进行比较,(也就是说,如果我们使用谓词date_closed>= add_months(sysdate, -60),会看到什么?)这个结果集会大很多。

                                                 Blocks           Rows
    Rows per block  Blocks           Rows Running total  Running total
    ------------- -------- -------------- ------------- --------------
                1        5              5             5              5
                2       22             44            27             49
                3      113            339           140            388
                4      281          1,124           421          1,512
                5      680          3,400         1,101          4,912
                6    1,256          7,536         2,357         12,448
                7    1,856         12,992         4,213         25,440
                8    2,508         20,064         6,721         45,504
                9    2,875         25,875         9,596         71,379
               10    2,961         29,610        12,557        100,989
               11    2,621         28,831        15,178        129,820
               12    2,222         26,664        17,400        156,484
               13    1,812         23,556        19,212        180,040
               14    1,550         21,700        20,762        201,740
               15    1,543         23,145        22,305        224,885
               16    1,611         25,776        23,916        250,661
               17    1,976         33,592        25,892        284,253
               18    2,168         39,024        28,060        323,277
               19    2,416         45,904        30,476        369,181
               20    2,317         46,340        32,793        415,521
               21    2,310         48,510        35,103        464,031
               22    2,080         45,760        37,183        509,791
               23    1,833         42,159        39,016        551,950
               24    1,696         40,704        40,712        592,654
               25    1,769         44,225        42,481        636,879
               26    1,799         46,774        44,280        683,653
               27    2,138         57,726        46,418        741,379
               28    2,251         63,028        48,669        804,407
               29    2,448         70,992        51,117        875,399
               30    2,339         70,170        53,456        945,569
               31    2,286         70,866        55,742      1,016,435
               32    1,864         59,648        57,606      1,076,083
               33    1,704         56,232        59,310      1,132,315
               34    1,566         53,244        60,876      1,185,559
               35   1,556         54,460        62,432      1,240,019
               36    1,850         66,600        64,282      1,306,619
               37    2,131         78,847        66,413      1,385,466
               38    2,583         98,154        68,996      1,483,620
               39    2,966        115,674        71,962      1,599,294
               40    2,891        115,640        74,853      1,714,934
               41    2,441        100,081        77,294      1,815,015
               42    1,932         81,144       79,226      1,896,159
               43    1,300         55,900        80,526      1,952,059
               44      683         30,052        81,209      1,982,111
               45      291         13,095        81,500      1,995,206
               46      107          4,922        81,607      2,000,128
               47       32          1,504        81,639      2,001,632
               48        3            144        81,642      2,001,776
               49  122,412      5,998,188       204,054      7,999,964
                  --------
    sum            204,054

    在这种情况下,大约有60%的blocks依然每个块持有原来的49行,但是表中的其他块几乎没有被删除,而是被完全清空。(如果您将第一个输出中的总块数与第一个报告中的总块数进行比较,您会注意到现在肯定有几个块(24个块)是完全空的)现在有多少块可用来插入?这里有一个快速的计算,我们的大部分块有49行,占了90%(default pctree = 10),因此,一个块将下降到75%的标记(即当ASSM将其标记为有空闲空间时),当它少于41行时(49 * 75 /90),在204,000个块中,大约75,000个符合这个标准(检查“运行的块总数”列) 

    索引空间

    上一节展示了一些简单的SQL,让您了解了表中将如何显示空间(或数据将如何保留)-我们可以对索引做类似的事情吗?答案必然是肯定的。但是,回答“在删除匹配谓词X的数据之后,索引会是什么样子”这个问题的代码运行起来要比运行表的代码开销更大。首先,这里有一段简单的代码来检查索引的当前内容:

    select
           rows_per_leaf, count(*) leaf_blocks
    from    (
           select
                   /*+ index_ffs(t1(client_ref)) */
                   sys_op_lbid(94255, 'L', t1.rowid)      leaf_block,
                   count(*)                               rows_per_leaf
            from
                   t1
            where
                   client_ref is not null
            groupby
                   sys_op_lbid(94255, 'L', t1.rowid)
            )
    group by
           rows_per_leaf
    order by
           rows_per_leaf
    ;

    对于‘SYS_OP_LBID()的调用是将一个表rowid作为它的输入之一,并返回一些类似于块的第一行的rowid的内容,而该块的地址是索引叶块的地址,索引块持有表rowid所提供的索引条目。另外两个参数是索引object_id(如果索是分区的,则是分区或者是子分区)和一个表示函数的特定用法的标志。在这个例子中是“L”。hint在目标索引上使用快速索引扫描是必要的,任何其他路径都可能返回错误的出结果-‘client_ref’不为空是必要的。以确保查询可以有效的使用index_ffs路径。

    对于我的初始化数据集,索引在每个块中都有448个索引条目,除了一个(大概是最后一个,192行)。即使这是简单的查询也要为了每个索引的要求而精心设计-因为索引快速扫描需要得到正确的结果,这就是我们不得不做一些不同寻常的删除操作,看看我们大量删除会怎么影响索引。下面是一个例子,展示我们如何找出试图删除5年多前打开的行对client_ref索引产生什么影响。

    select
           rows_per_leaf,
           count(*)                                      blocks,
           rows_per_leaf * count(*)                          row_count,
           sum(count(*)) over (order by rows_per_leaf)                 running_blocks,
           sum(rows_per_leaf * count(*)) over (order by rows_per_leaf) running_rows
    from   (
           select
                    /*+ leading(v1 t1) use_hash(t1)*/
                    leaf_block, count(*) rows_per_leaf
           from    (
                    select
                            /*+ no_mergeindex_ffs(t1(client_ref)) */
                            sys_op_lbid(94255, 'L',t1.rowid)       leaf_block,
                            t1.rowid                                rid
                    from
                            t1
                    where
                            client_ref is not null
                    )       v1,
                    t1
           where
                    t1.rowid = v1.rid
            and    date_open < add_months(sysdate, -60)
           group by
                    leaf_block
           )
    group by
           rows_per_leaf
    order by
           rows_per_leaf
    ;

    正如您所看到的,我们从一个内联视(暗示不可合并)图开始将索引块id附加每个表的rowid上,然后将这组行id连接回表-通过rowid连接并强制进行散列连接。我已经暗示了散列连接,因为它(可能)是最有效的策略,但是尽管我引入了一个leading()提示,但我没有包含关于交换(或不)连接输入的提示-我将让优化器决定这两个数据集中哪个更小,由此来更适合的构建哈希表。

    在这种特殊的情况下优化器能够使用一个仅索引的访问路径来查找date_open 比五年前跟早行的所有rowid。尽管如此(部分原因是我的pga_aggregate_target相对较小,散列连接溢出到(固态)磁盘),查询耗时3分15秒,而上一个查询在缓存整个索引时恰好运行了1.5秒。以下是输出的摘录:

                                                 Blocks           Rows
    Rows_per_leaf   Blocks           Rows Running total  Running total
    ------------- --------  ------------- ------------- --------------
             181        2            362             3            458
             186        2            372             5            830
             187        2            374             7          1,204
             188        1            188             8          1,392
    ...
             210      346         72,660         2,312        474,882
             211      401         84,611         2,713        559,493
    ...
             221      808        178,568         8,989      1,921,410
             222      851        188,922         9,840      2,110,332
             223      832        185,536        10,672      2,295,868
    ...
             242      216         52,272        21,320      4,756,575
             243      173         42,039        21,493      4,798,614
             244      156         38,064        21,649      4,836,678
    ...
             265        1            265        22,321      5,003,718
             266        1            266        22,322      5,003,984

    我们要修改22322个叶块——这是索引中的每一个叶块;我们从一个叶块中删除的行数从1到266不等。我一次从83行输出中选择了几行,但是您可能仍然可以看到该模式似乎遵循正态分布,以222(50%)为中心。

    如果这样删除我们应该很清楚,我们将花费大量的精力来更新这个索引;即使这样,“每个叶块删除多少行”这个简单的数字也不能告诉我们要做的工作的全部内容。我们不知道我们是否会(例如)在同一时间删除所有266个索引条目从最后一块上面显示删除完成,我们将非常随机地在索引周围跳跃式来回,并发现自己不断地重新访问该块,以便一次删除一个索引条目。因此在下一期中,我们将研究需要考虑工作负载的哪些方面,以及不同的删除策略会对工作负载产生怎样的影响。

    原作者: Jonathan Lewis

    原文地址:https://www.red-gate.com/simple-talk/sql/oracle/massive-deletes-part-2/

    | 译者简介

    汤健·沃趣科技数据库技术专家

    沃趣科技数据库工程师,多年Oracle数据库从业经验,深入理解Oracle数据库结构体系,现主要参与公司一体机产品安装、测试、优化,并负责电信行业数据库以及系统运维。

    展开全文
  • 问题描述:一个日志文件里逐行存储着 时间 ip 这种形式日志,现在需要让你使用linux命令查找出日志文件中访问量最大10个ip 怎么处理? 1.首先创建模拟数据 这里博主用python写了个创建模拟数据的脚本 文件内容格式...

    写这篇博客的主要原因就是之前面试的两家公司都有问到这个问题,所以便着手研究了一下它的解决方法
    问题描述:一个日志文件里逐行存储着 时间 ip 这种形式的日志,现在需要让你使用linux命令查找出日志文件中访问量最大的10个ip
    怎么处理?
    1.首先创建模拟数据
    这里博主用python写了个创建模拟数据的脚本 文件内容格式 : 时间戳 ip

    #!/usr/bin/python
    # -*- coding:UTF-8 -*-
    #filename = testdata.py
    import random
    import time
    file = open('/ip.txt','w');
    for i in range(0,500):
       num = random.randint(1,10)
       rand_str = time.time()
       fir_1 = random.randint(0,255)
       sec_2 = random.randint(0,255)
       thr_3 = random.randint(0,255)
       fou_4 = random.randint(0,255)
       for j in range(1,num+1):   
          file.write(str(rand_str)+' '+str(fir_1)+'.'+str(sec_2)+'.'+str(thr_3)+'.'+str(fou_4)+'\n')
    file.close() 
    print 'create sucessful!!'
    

    2.输入命令

    cat ip.txt|awk -F" " '{print $2}'|sort|uniq -c|sort -nrt " "|awk -F" " '{print $2}'|head -10  
    

    每一步命令解释:
    cat ip.txt 将ip.txt文件内容输出到终端
    | 通过管道符|将左边命令输出作为右边命令输入(后面|功能类似)
    awk -F" " ‘{print $2}’
    -F 指定输入文件折分隔符 -F" ": 以空格分隔
    {print $2} 分隔后每一行就分成了时间戳和ip两个单元$1指时间$2指ip print $2 即输出ip
    sort 对输出ip进行排序
    uniq -c 检查及删除文本文件中重复出现的行列 -c或–count 在每列旁边显示该行重复出现的次数。
    此时输出的数据格式为 出现次数 ip
    sort -nrt " " 对输出结果排序 -n : 依照数值的大小排序 -r : 以相反的顺序来排序 -t : <分隔字符> 指定排序时所用的栏位分隔字符
    接着继续用awk 将数据第二列ip输出
    head -10 取前十条数据
    命令执行结果:
    在这里插入图片描述

    展开全文
  • 错误案例 【现象描述】 芝麻开门项目在周末两天时间内共对...到了周一,由于中文站的访问量一下子增加,导致memcached写入死锁。从上午九点左右开始,发现阿里助手首页打开很慢,中午到下午两点响应时间进一步增加。

    错误案例

    【现象描述】

    芝麻开门项目在周末两天的时间内共对1650万左右的数据进行了订正,订正当天应用正常。到了周一,由于中文站的访问量一下子增加,导致memcached写入死锁。从上午九点左右开始,发现阿里助手首页打开很慢,中午到下午两点响应时间进一步增加。下午三点半左右,随着cache的会员逐渐增多,应用逐渐恢复,下午五点开始基本恢复正常。

    【错误代码】

    While(存在未处理的数据) {
        Member = readFromDB(); // 从数据库中逐一读取
        update(member); // 更新这个会员数据,并默认清空该会员cache中的数据;
        logger.info(member);
    }
    

    错误分析

    在大数据量订正的时候,如果该数据也保存在cahce中,要把大数据块分成小块,每次只处理小块数据,并要防止cache数据被清空。因为在系统高访问的情况下,高并发的写入cache,每一次写入cache都会加锁,而mencached本身有缺陷,在高并发的时候,等待写入的请求直线增加,会导致写入无限制延长,甚至写入死锁。

    正确用法

    提取所有数据保存到文件file1;

    评估确定每天允许更新的数据量 k,分块处理大数据量;

    设置定时任务,每天执行一次;

    任务代码如下:

    i = 0;
    While(i <= k){
        member  = readFromFile(file1);
        Update(member);
        putBackToCache(member) // 必要时需要这么做,但是需要和架构师讨论;
         logger.info(member);
        removeFromFile(file1);
        i ++;
    }
    

    测试关注点

    1、测试环境下执行任务,使得cache数据被清空;

    2、模拟用户高并发访问的情况,启动多个进程进行持续访问;

    3、打开系统页面,检查系统响应时间是否增加,以及是否可以接受,检查系统是否有死锁的日志。


    展开全文
  • 教你如何迅速秒杀掉:99%海量数据处理面试题 https://blog.csdn.net/v_july_v/article/details/7382693 十道海量数据处理面试题与十个方法总结 https://blog.csdn.net/twlkyao/article/details/12037073 ...
  • 2、使用memcache缓存技术,将动态数据缓存到内存中,动态网页直接调用这些文件,而不必在访问数据库。 3、禁止外部盗链。 4、外部网站图片或者文件盗链往往会带来大量负载压力,因此应该严格限制外部对自身...
  • 在表上频繁update和delete操作会导致索引出现很多空间碎片,从而使得访问该索引SQL查询效率下降,通过rebuild index,可以回缩空间碎片,并提供查询效率。 2. 问题描述 OS信息: Solaris 10 数据库信息: ...
  • 简单查询数据库登录逻辑,使用mysbatis-plus进行dao层代码生成(吐槽一下这个工具,真是方便一时爽,后面维护难,比较喜欢自己能够组装和优化sql,大数据量插入时候mybatis-plus性能极差都是生成单条插入sql...
  • 2、使用memcache缓存技术,将动态数据缓存到内存中,动态网页直接调用这些文件,而不必在访问数据库。3、禁止外部盗链。4、外部网站图片或者文件盗链往往会带来大量负载压力,因此应该严格限制外部对自身图片...
  • 使用Perl hash来分析大量数据

    千次阅读 2011-09-04 06:39:59
    在perl中,数组和哈希是两种极为重要数据结构,它们有各自不同用处。其最为重要区别笔都认为是前者是线性结构,而后者为...接公司运营要求,统计天翼手机用户每个月对某一业务系统的访问量,需要大致可以描述如下:
  • 问题描述:我们要访问的表是一个非常大的表,四千万条记录,id是主键,program_id上建了索引。执行一条SQL:select * from program_access_log where program_id between 1 and 4000这条SQL非常慢。我们原以为处理...
  • 两种数据结构都是线性表,在排序和查找等算法中都有广泛应用 一、各自特点: 数组: 数组是将元素在内存中连续存放,由于每个元素占用内存相同,可以通过下标迅速访问数组中任何元素。但是如果要在数组中增加一...
  • 两种数据结构都是线性表,在排序和查找等算法中都有广泛应用 一、各自特点: 数组: 数组是将元素在内存中连续存放,由于每个元素占用内存相同,可以通过下标迅速访问数组中任何元素。但是如果要在数组中增加一...
  • 描述: 列表页会加载此用户所有拥有二维码门票列表,用户点击单个二维码将进入二维码详情页面,此页面会查询很多次将详情页面所有需要的数据加载至页面上,访问数据库操作比较多 问题描述访问登录页面,二维码列表...
  • 随着Internet发展、脸颊存储设备应用数据大量增长、对分析论更深入理解以及对数据访问的期待,数据以更加有趣和独特方式受到影响。数据访问设计模式目的是帮助构造出能够容易地处理素有这些数据对象...
  • 全书结构严密、层次清晰,以浅显易懂语言进行描述,并结合大量实例向读者阐述了较为复杂的数据访问问题,帮助读者理解掌握。 本书读者对象是对Visual Studio.NET和Visual Basic有一定了解中级用户。本书可作为...
  • 力再次得以展现:基于统一图遍历算法模版,分别实现了深度优先、广度优先和最佳优先三类 遍历算法。实际上,这三类算法本身仍然以模版形式实现,包括边分类、可达分量、连通分量、最 短路径以及最小生成树在内...
  • 20170208大量Http请求close_wait问题

    千次阅读 2017-02-08 17:54:38
    解决大量http请求close_wait问题1.... 我们知道在Linux环境中,任何事物都以文件形式存在,通过文件不仅可以访问常规数据,还可以访问网络连接和硬件。如TCP和UDP等,系统在后台都会为该应用程序分配一个文件描
  • 树这种结构极大的缩短了数据访问时间。什么是树呢?它是怎么做到提高访问效率的呢?树可以用几种方式定义,定义树的一种自然方式是递归方式,一棵树是一些节点的集合,这些集合可以是空集;若不是空集,则树由根...
  • 一,问题描述 如果给你一个集群一天...首先遇到这样问题首先要想到,这种实际情况可能产生海量数据是不适宜用排序算法做,即时快排堆排能够保证排序评价时间复杂度为O(nlogn),但数值一旦起来这种排序...
  • 本节书摘来自华章计算机《大数据分析原理与实践》一书中第1章,第1.3节,作者:王宏志 更多章节内容可以访问云栖社区“华章计算机”公众号查看。 1.3 什么是大数据分析 1.大数据分析定义数据分析指是用适当...
  • 几年前,您必须去Blockbuster商店购买自己喜欢电影DVD,但是在当今互联网时代,情况恰恰相反,如今,互联网使人们可以在线访问大量资源。 Netflix,亚马逊,Hulu等网站上有大量电影收藏。人们很难选择看什么。 ...
  • 不同于Windows平台高效线程机制, Linux/Unix系统早期通过多进程来解决Web规模并发访问量的问题. 而随着Linux内核改进, 单纯增加进程数量方式也慢慢被弃用, 转而使用单进程异步IO接口, 比如epoll(Linux), ...
  • 现有海量日志数据保存在一个超级大的文件中,该文件无法直接读入内存,要求从中提取某天出访问百度次数最多的那个IP 2.思考过程 (1)面试中若题目提到大文件等,其实就是告诉你数据量大,不能一次性加载到内存中,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,295
精华内容 518
关键字:

数据访问量大的描述